最近在做 LetPot的客服问答系统。200 多篇知识文档，涵盖产品规格、植物百科、FAQ、官方博客。 目标是让 AI 自主回答用户关于设备使用和植物种植的各种问题。
这个项目让我有机会把之前的一个想法真正落地验证。
去年底看 Andrew NG 的 Agentic AI 课程时，agentic 这个词才刚被讨论，连如何定义的都未达成共识。Andrew 的定义是：
Agentic AI 是一种构建软件的新方式——利用大语言模型（LLM）完成复杂任务中的部分或全部步骤。与单次响应提示不同，Agentic Workflow 使 AI 能够规划多步骤流程、迭代执行，并通过反思和工具使用来改进输出。
课程看完后耳目一新，当时心里埋下了一个种子，知道或许随着 Agent 能力的提高，这一天会到来。 没想到刚进入 2026 年，以Claude Opus 4.5 发布为时间节点，模型的 Agentic 能力被意识到已经足够强到能够独立运行长程任务完成复杂的项目了。 紧接着 Claude Code、OpenClaw、Hermes Agent， 几乎每家大厂都推出自己的 Claw 或 Agent 产品，各式各样的代理层出不穷。这个范式正在被主流拥抱。
从 Pipeline 到 Agent
Andrew NG 在 DeepLearning.AI 的 Agentic AI 课程里讲了四个核心设计模式：
- Loop (迭代执行)：不是一次性生成，而是多步骤循环执行
- Reflection（自我审视）：AI 能批评自己的输出并持续改进
- Tool Use（工具使用）：能调用外部数据库、搜索引擎、代码执行等
- Planning（任务规划）：将复杂任务分解为可执行的步骤
- Multi-agent Collaboration（多智能体协作）：多个专门化 AI 系统协同完成复杂工作流
课程用原生 Python 实现，不依赖任何框架，把每一步都摊开来看。对我触动最大的不是某个具体模式，而是整个系统架构思路的范式转变。
传统做法是 pipeline workflow：用户输入 → 意图识别 → 路由 → 检索 → 生成 → 过滤 → 输出。每一步都是确定性的，流程图画得明明白白。这很工程化，但也意味着每一个新需求都要改流程，每一种边界情况都要加分支。
Agentic workflow 完全不同。你不画流程图，你给 AI 工具和上下文，然后让它自己决定怎么走。对确定性输出的要求降低了，换来的是对新场景的自适应能力。
"Context, not control" 这个表述借鉴了 Netflix 的管理哲学。不微管理，而是提供充分的上下文信息，让人（或 AI）自主做出好的决策。
Agent Loop 的真实面貌
市面上的 Agent 开发框架很多。LangChain、LlamaIndex、还有像 OpenClaw 底层的 pi agent 这类本地 coding agent 框架。我最终选了 Vercel AI SDK，原因很具体。
这个项目需要作为独立的无状态 API 服务部署，安全性要求高，必须与文件系统和操作系统完全隔离。 像 pi agent 这类框架天然是为本地开发环境设计的，可以读写文件、执行 shell 命令、操作浏览器。 但在线上客服场景里，所有对"文件"的访问都应该是对数据库的查询，Agent 不应该接触到宿主机的任何东西。
LangChain 我之前试过，编排实现复杂耗时，调试困难，最重要的是对新需求的适应能力差。 每次业务逻辑变化都要重新接线。
Vercel AI SDK 的吸引力在于它的 loop 自定义灵活性。 你可以精确决定用什么工具、每个环节的提示词、每个步骤执行后的钩子和日志记录。 它不替你做决策，但把做决策需要的所有控制点都暴露出来。为可观测性提供了非常多可能。
用 Vercel AI SDK 的 streamText 搭建 Agent Loop，核心代码其实非常简洁。
你告诉 SDK 三件事：模型是谁、工具有哪些、上下文是什么。剩下的，SDK 和 LLM 之间自动循环。
整个流程设计十分简单，一张图就能看懂，但就是这个简单Loop，给了Agent 施展能力的空间。 整个循环过程不需要写一行 if/else 来编排。LLM 自己决定调什么工具、调几次、什么时候停。SDK 只负责执行和传递。
循环什么时候停？两种情况：LLM 认为它可以回答了（返回文本而非工具调用），或者达到了你设定的最大步数。为了防止无限循环，我在最后一步会强制切换为"禁止调用工具"模式，逼 LLM 收敛输出。这是少数几个我主动施加控制的地方。
工具不是指令，是能力描述
这是 Agentic 方式里最反直觉的部分。
LLM 看不到你的代码实现。它只看到工具的 description（描述文本）和参数的 schema（结构定义）。这两样东西就是 LLM 做决策的全部依据。
比如我的搜索工具，description 里写了一句："Returns titles, summaries, and relevance scores. Use get_page to read full content."
这句话的信息密度很高。它告诉 LLM：search 只返回摘要级别的信息，如果需要完整内容，你应该接着调 get_page。LLM 从这句话里学到了两个工具之间的协作关系，然后在实际运行中自己串联起来。
我不需要写"如果搜索到结果，则调用 get_page 获取详情"这样的编排逻辑。LLM 从 description 的语义中推断出了这个协作模式。
好的 description 是一种"上下文工程"。你在用自然语言教 AI 什么时候该用什么工具，以及工具之间如何配合。
观测AI的决策和实践的过程
第一次跑通完整流程的时候，让我真正惊讶的不是最终答案的质量，而是 AI 的决策过程。
打开思考链（DeepSeek 的 thinking mode），你能看到它在想什么。不只是思考链，每一次工具调用的输入参数、返回结果、调用耗时全部实时可见。面对一个用户问题，它的思考路径非常像一个人会做的事：先分析问题的核心是什么，粗搜索扫描目录找到相关主题，细搜索定位到具体原文，然后反思是否拿到了足够信息来回答。如果不够，它会继续搜索别的维度。最后在输出前还会检查一遍是否真的回答了用户问的东西。
整个过程使用 DeepSeek V4 Flash，速度非常快。
最重要的是，过程完全可观测。AI 的每一步思考、每一次工具调用、每一个中间结果都被记录下来。 复杂的回答有迹可循。这是后续持续优化的关键。 如果回答错了，我可以回溯看到底是哪一步的信息不对或者决策有误，而不是面对一个黑盒猜测。 只有具备观测能力，才能发现问题在哪里，进而才有可能去优化知识库、调试工具调用能力、或者优化系统提示词增加要求和约束。
我管上下文，AI 管决策
在这个架构里，作为开发者的工作本质上变了。 我不再是在写业务逻辑和控制流，而是在做"上下文工程"。
System Prompt 不是一份指令清单，它是 AI 的身份认知和行为边界。 它告诉 AI"你是谁""你的知识来源是什么""什么该做什么不该做"。 加上工具的 description，加上用户的历史消息和账号信息，这三样构成了 AI 做决策时的全部上下文。
上下文管理是这个方案里最大的工程挑战。每一个 step，SDK 会把完整的历史消息重新发送给 LLM。 这意味着多步 agent 的 token 成本是累积的。第三步的请求包含了前两步所有的工具调用和返回结果。
实际运行中遇到过对话太长导致 LLM "忘记"系统提示词的情况， 或者长文章（含有大量噪声信息）处理明显变慢。 这都是上下文窗口的物理限制。后续考虑把长文档拆分为按主题的段落，减少单次检索的噪声。
系统的最后一道防线
系统里还有一个 checker 工具，它是做安全性和事实核查。 这个设计不是一开始就有的，而是在思考线上生产环境的需求时加上去的。 它会带来延时，但是对需要安全合规输出的应用来说，几乎是必选项。
对于一个面向真实用户的客服系统，AI 的回答必须有底线。 规避错误、非法、违规的回复是基本要求。 更重要的是，需要防范提示词注入导致 AI 失控的风险。
我的做法是让 checker 作为一个独立的"外部审查员"存在。 AI 在输出最终回答前可以调用它来验证：内容是否安全？事实是否有知识库依据？是否提到了不该提的东西？
这个设计的关键是它也是一个 tool，不是硬编码的后处理步骤。 AI 自己决定什么时候需要审查。对于简单问题可能跳过，对于涉及产品规格或故障排查的回答则主动调用验证。
我的思考
做完这个项目，我有几个比较明确的判断。
关于 Agentic 和编排的边界。 给 Agent 自主空间意味着它犯错的可能性更大，但也意味着它的能力上限更高。 这是一个权衡，但我认为编排式 AI 最终会消失。 随着模型能力的提升和 Agent harness 工具链的完善，让 AI 在受控空间内自主探索会成为默认选项。 更重要的是提供合适的工具让它在一定边界内勇敢尝试，而不是替它规划每一步怎么走。
关于可观测性。Agentic 方式能成立的前提是你能看到 AI 在干什么。 思考链、工具调用记录、中间结果，这些不是 nice-to-have，是系统能持续优化的基础。 没有可观测性的 Agent 系统就是一个高级黑盒，比传统 pipeline 更难调试。
关于进化的可能性。 目前的系统是"静态"的：知识库固定、工具固定、不从交互中学习。 但 Agentic 架构天然留出了进化空间。 如果给 Agent 加上记忆能力（记住用户的设备和偏好）、知识缺口发现能力（主动标记知识库里缺失的信息）、策略学习能力（从 eval 结果中调整搜索策略），它就能从"静态工具"变成"越用越聪明的伙伴"。 看看 Hermes Agent 那种"closed learning loop"的思路，Agent 从经验中自主创建技能、从使用中自我改进，这是下一个阶段的想象空间。
最后一点。Andrew NG 在课程里强调了一件事：能否成功构建 Agent 系统，最大的预测因子不是技术能力，而是是否有纪律性地做 eval 和 error analysis。 这一点我深有体会。让 eval 数据引导你改什么，而不是靠直觉猜，这个原则对 Agent 开发和传统软件开发一样适用。 这个项目也构建了完整的eval体系，这对agent进行持续迭代至关重要。
只有看到了问题，才有可能解决问题