昨天 23:13 渤海大学后端工程师发布于辽宁

关注

AI Agent 漫谈

前言

当我们尝试将网上开源的大模型部使用Ollama的方式署在本地，就会发现，呈现给我们的只有一个黑色对话框。想要提供给他人使用，最佳方式还是提供一个网页或者API接口。对于后者，Ollama已经实现，你可以使用下面的地址

http://localhost:11434

假设你继续跟着官方教程，使用python或者其他语言，就可以制作一个简单的聊天助手，恭喜你完成了一个 Agent 的开发。但是距离企业中落地的 Agent 还有一点距离，接下来，我将带你逐步补齐。

alt

AI 核心概念

从机器学习（Machine Learning），自然语言处理（NLP）开始说起，对于作为后端的我，有点难为了。只是应用层开发，了解以下足够。

Model 模型

即使都叫 DeepSeek，下面也分不同种的模型，对于我们开发而言，需要给出正确的模型名字。 alt

图源DeepSeek API开放平台

base url：每家模型的基础url，使用其他功能需要在后面拼接。比如普通的聊天就是

https://api.deepseek.com/chat/completions -- 后面追加/chat/completions

上下文长度：一次话题支持的最大上下文。超过就会开始出现幻觉，失忆等情况。
输出长度：一次对话的最大上下文。
Json Output：只输出json格式回答。算是打开AI赋能应用的基础，确保了固定格式。
Tool Calls：给于大模型眼，与手脚，让他可以操作其他工具 or 系统。

Prompt 提示词

经常使用DeepSeek的同学肯定不陌生，提示词嘛，每天给他对话的输入的内容就是提示词。对也不对，在整个AI 应用中，输入的提示词只占全部工程的一部分。

在一个助手诞生前，还有一个System Prompt，给于这个助手身份。直接询问就可以得到。 alt

（也可能是他忽悠的）

除基本设定外，还有软件的设定。将原有提示词增强。比如，用大模型最擅长的翻译，可以这样

System Prompt : 你是一个翻译助手，可以高效的翻译用户的句子。

工程的再封装：翻译下面的句子：{用户的话}

Tokens 词元

大模型推理的最小单位，也是上下文的单位。其实现在Token还是习惯不翻译。或者更直观一点，也有人叫他代币，毕竟很多卖模型API的商家，是按Token算钱的。

对于中文语境来说，一个字或者一个词都可能算一个Token。比如：“人工智能”可能被当作一个token处理。平均来说，1个中文字约等于1.3-1.5个token。

Retrieval Augmented Generation，RAG 检索增强生成

现在的大模型产出内容不是凭空想象的，而是经由大量知识计算来的，而且有一定时间节点的，所以是预训练模型。当需要使用企业内部知识，或最新的公开知识时，就会胡编了。

如果没有工程化的应用开发，我们完全可以手动将对应的知识复制粘贴给大模型。

以上手动的识别，检索，反馈给大模型也就是RAG要解决的问题。

向量数据库

其实大模型是不需要什么额外存储的，推理都发生在内存中。但是有了RAG后，存储也变成了必要项。为啥要使用向量呢？因为模型的推理过程之一，就是需要把非结构化的文字，转为结构化的数据。恰好，向量可以做到。

向量：一维可以表示前后，二维便在平面上有了更具体的指向。三维四维等N维之后，任何token都可以表示在这个N维坐标系中。知识就可以这样以向量关系存储在这里。
数据库：存储向量来说，其实传统的关系型数据库Postgresql也可以做到，加上pgvector插件，更是可以取代一些功能。但检索速度，功能完备上，还是独立的向量数据库更强。

AI Agent 编排

alt

Agent开发整体是以“用户发起需求→Agent完成任务→输出响应”为脉络。所以无论是Dify、Coze，还是手搓一个工作流，核心离不开这些流程组件。加入不同节点，也只是得到更确定性的答案。下面，开是分阶段介绍。

需求接收与Prompt构建

用户提出自然语言需求（如“查询客户A的年度消费趋势，并分析复购原因”）。

对需求进行“结构化加工”：补充业务规则（如“只分析近2年数据”）、明确工具调用优先级（如“优先调取CRM系统数据，再用数据分析工具可视化”），最终生成精准的LLM可执行Prompt。

知识与能力增强（按需触发）

LLM自身能力有限，需通过工具、RAG、记忆系统扩展能力，这一步是Agent区别于纯LLM的核心：

① 工具调用

若任务需“执行外部动作”（如“导出订单报表”“发送邮件通知”），选择对应工具（如ERP系统的报表API、邮件服务SDK），工具执行后将结果返回给LLM。

② 私有知识检索（RAG流程）

③ 上下文记忆

在工程化中，记忆其实是一个大难关，模型本身的框架已经决定了记忆是有限的。再与大模型交流的过程中，有95%以上的内容是过程推理，所以普遍的做法是让另一个会话去压缩总结。

而在超长任务中，记忆的处理分的则更详细。比如Manus这种，内部就是大量的Markdown，有长期准则性的冷记忆，一般不会变化。还有工作时产生的临时上下文文档，作为热记忆，随时可压缩，可变化。最后将二者提取一起放在工作记忆中。

初步响应、迭代与后续

整合了答案后，还需要再次判断问题没有解决，或者需要澄清的用户问题。这样的结果需要我们优化Prompt，加入节点。

当形成了较为满意的答案，开始将结果存入记忆中。有些甚至需要放入向量数据库中。

Agentic AI

2025 称之为AI Agent元年，在一年的累积后，Agent 范式逐渐形成。渐渐的，很多简单流程，不需要人来规划。只要写好四个模块，AI 自主串起来。

alt

AI Agent 开发Q & A

最近在群里和很多人去聊天，收集了一点问题。放在文章最后。

AI 与开发语言?

理论上来讲，AI 开发与语言无关，无论是前端后端都可以用常用的语言写。不过，如果你想从头开始，拒绝重复造轮子，可以选择Python。

手搓还是选择Dify、Coze？

后者对于没有研发团队，或者无研发能力的个人来说，是个很好的选择。有时候，开发也可以优先选择后者来快速体验流程。

快速入门？

有一定开发能力：直接上手Github上比较热门的项目，AI 对你来说，只是多一个特殊的业务。刚起步，对于AI不了解，先去模仿，用Dify这些玩一下。然后手动实现。

AI Agent 比较成熟的落地场景

客服，在线教育，自媒体，旅游相关，数据分析

AI 项目达不到预期，从哪里入手？

1️⃣先当“需求翻译官”，把模糊目标变成“可触摸的标准”。业务方想要的是“减少人工介入”“提升客户满意度”，还是“降低培训成本”？不同目标对应的技术方案完全不同。怎么做？试试“用户旅程地图法”：拉着业务方一起画一张图，标出客户咨询的典型路径（比如“查物流→不满意→要补偿→转人工”），在每个节点标注“当前人工处理的痛点”（比如“客户重复说单号”“补偿规则记混”）。这时候你会发现，真正的目标可能是“在‘查物流’节点自动完成90%查询，且错误率＜5%”，而不是笼统的“更智能”。

2️⃣输入垃圾，输出只能是垃圾。

3️⃣用多维度评估代替单一指标。小A一开始只看“准确率”（回答是否正确），但业务方吐槽“客户觉得机械”——因为他没考虑到“对话流畅度”“情感匹配度”这些隐性体验。怎么做？建一个“动态评估仪表盘”，至少包含四类指标：任务完成类（核心）：问题解决率、转人工率；效率类：平均对话轮次、响应时间；体验类：客户打断次数、负面反馈关键词（“听不懂”“重复”）；鲁棒性类：对抗测试（故意说错话、打错别字）的成功应对率。