前言
过去两年，"AI Agent"几乎是每篇AI技术文章绕不开的关键词。
做一个Demo其实并不难。把搜索、数据库、代码执行环境接上，让模型自己规划任务、调用工具，几天时间就能做出一个看起来"会自动干活"的AI。
但Demo和产品之间的距离，往往比想象中更长。
模型可能胡编内容。RAG可能检索不到真正需要的资料。Agent可能反复调用同一个工具，任务跑到一半卡死。Token和延迟不断增加。 更让人担心的是，模型拿到系统权限之后，执行了本来不该执行的操作。
AI Agent真正难的地方，是让它在真实的业务环境里持续稳定地把事情做完。
从Demo走向生产，实际上要经过一条完整的工程链路
我们可以把它简单理解成：
问题定义 → 模型能力 → 知识获取 → 工具执行 → 流程控制 → Agent决策 → 状态管理 → 安全控制 → 评估监控 → 持续优化
成熟的做法是按问题决定需要哪些能力，整套链路按需组装。
所以接下来真正值得讨论的，是一个AI Agent到底需要哪些工程能力，才能从"会回答"真正走到"能干活"。
先想清楚问题，再决定要不要做Agent
工程师遇到问题，第一反应往往是"上Agent"。
但Agent不是万能工具。
一个固定的合同审核流程：上传合同、OCR识别、信息提取、规则校验、生成报告，每一步都已经确定。这种场景用传统Workflow就足够稳定，让Agent自己决定每一步反而会带来不必要的出错风险。
分析一家公司的经营状况是另一种场景。需要搜索公开资料、读取财报、比较数据、发现异常后继续调查，下一步往往取决于上一步的发现。这种流程本身不确定的情况，才适合Agent。
工程化路径应该按问题匹配技术。
Prompt和上下文调优是第一步。模型缺的是企业内部知识或实时数据，引入RAG比继续改Prompt更直接。需要让模型访问外部系统或执行操作时，必须增加Tool。业务流程本身固定的情况，比如合同审核或报告生成，用Workflow更稳定，每一步都可预测可审计。任务复杂、下一步取决于上一步结果的情况，才考虑Agent。
让问题决定架构，而不是让架构反过来定义问题。
Prompt和 RAG：先让模型"会用"，再让它"有资料"
最先应该挖掘的，是模型本身的能力。
模型表现不好，原因常常是任务描述不清楚、上下文不完整、输出格式没有约束，或者缺少必要的示例。这些问题优先通过提示词工程和上下文工程解决。
如果模型缺的是企业内部制度、产品文档、项目代码、实时数据这些外部知识，继续改Prompt没有意义，需要RAG。
RAG让模型回答问题时，有真实、相关的资料可以参考。整个过程可以拆成几步。用户问题进入系统，系统检索相关知识，筛选和排序之后构造上下文，最后由模型生成答案。每一个环节都会影响最终效果。
工程上容易踩的坑，是把RAG当成"把PDF扔进向量数据库就完事"。真正难的是细节。文档按什么粒度切分、要不要重排、一次检索多少内容、如何避免无关信息污染上下文，每一点都需要根据业务数据反复调优。
RAG工程要解决的核心问题，是把外部知识可靠地送到模型面前。
Tool：让模型从"会说"走向"会做"
RAG解决的是"模型缺知识"的问题。还有一类更基础的问题，模型知道该做什么，却没有能力真正去做。
模型知道怎么查询订单，但没有订单系统权限。知道怎么查数据库，却没有数据库接口。知道怎么发邮件，却无法调用邮件系统。
这种时候需要Tool Calling。模型负责决定下一步需要做什么，外部工具负责把这件事情真正执行掉。
系统的形态开始变化。理解任务，模型判断，调用工具，获得结果，继续处理。每一步都可以被记录和审计。
到这里，AI才开始从"会说"变成"会做"。
但Tool不等于Agent。如果整个流程还是固定的，模型加Tool加Workflow就足够解决问题，引入动态决策反而会带来不必要的复杂度。
Workflow和Agent的区别：谁决定下一步
这是Agent文章最容易讲模糊的地方。
Workflow和Agent都可以使用大模型、RAG和工具。两者最大的区别在控制权，也就是谁决定下一步做什么。
Workflow由程序定义流程，模型扮演流程中的一个环节，按预设路径逐步执行。
Agent把决策权交给模型。模型根据当前状态判断下一步行动，观察结果后再做下一步判断。
所以Agent适用于这种任务，目标清晰，但执行路径无法提前完全确定。程序定义的Workflow在这里不再够用。
Agent本质上是一个受控的决策循环
从工程角度看，Agent更像一个状态机。
Agent的状态机流程是这样运转的。从当前状态出发，模型先做判断，根据判断结果执行工具调用或产生动作，然后观察工具返回的结果，更新当前状态，进入下一轮判断。
这个循环必须受控。什么时候继续、什么时候停止、失败多少次需要退出、最多执行多少步、超过Token预算怎么办、工具一直返回异常怎么办，这些规则必须提前定义清楚。
一个生产可用的Agent和"无限自主"的AI，差别就在这些规则上。
State、Memory和Context Management
Agent执行复杂任务时，必须知道自己做到了哪一步。
State关心当前任务，记录现在正在做什么、哪些工具已经调用、上一步的结果是什么。
Memory关心跨任务的信息，比如用户过去有什么偏好、之前做过哪些类似的任务。
生产环境里，Context Management往往比Memory更关键。
Agent运行时间越长，上下文越容易膨胀。历史对话、工具结果、中间状态全都塞进上下文，成本快速上升。真正重要的内容反而更难被模型看到。
成熟的做法是有选择地保留信息。哪些长期保留、哪些可以压缩、哪些应该丢弃，需要时再去检索。Context Engineering在最近一年变得重要，原因也在这里。
Guardrails：给模型加边界
到这里，系统已经具备模型、知识、工具、状态和动态决策能力。
但还有一个工程问题必须解决。Agent到底允许做什么。
查询订单和删除订单不是一个风险等级。读取资料和执行退款也不是一个概念。
生产环境必须加Guardrails，也就是护栏机制。
实际落地按风险分层。低风险操作可以直接执行，比如读取商品信息。中等风险的操作需要增加规则校验，例如修改订单状态前要二次确认。删除数据或执行退款这样的高风险操作必须人工介入。
模型生成的动作不能直接等于系统执行权限。模型说"删除数据"，系统不应该直接执行删除。模型负责判断，系统负责授权。
真正高风险的操作，还需要权限控制、参数校验、审计日志和必要的人工介入。
这是AI Agent和普通聊天机器人在工程上的关键区别。模型一旦拥有行动能力，一次错误的代价就从"答错一句话"升级到"执行错一件事"。
Evaluation和Observability：先看能不能跑，再看为什么跑不好
很多Agent项目的问题都出在评估环节。
开发完成，测试几个用例，看起来不错，就上线。一个任务成功一次，不能证明系统可靠。
更可靠的问题是，跑100次，有多少次成功。
Agent的评估不能只看最终答案是否正确。还要看执行过程是否合理，工具选择和参数是否准确，有没有越权或安全问题。"最终结果对了但中间过程错"是Agent特有的失败模式，传统LLM只看最终答案，Agent需要关注整个执行链路。
如果评估发现失败，下一步是定位失败原因。
工程团队需要回答的问题包括使用了什么模型、输入了什么上下文、检索到了什么内容、调用了哪些工具、每一步用了多少Token、哪一步出错、为什么出错。
这就要求生产Agent具备完整的日志和Trace能力。一次任务的执行过程应该能完整还原。
失败能被定位，定位之后才能形成数据，数据才能用来优化Prompt、RAG、工具、Workflow甚至模型本身。
完整闭环包括运行、评估、发现问题、分析原因、优化，然后再次运行。
微调不是必经之路
按问题匹配技术，落到训练上同样成立。
模型缺企业内部知识，RAG通常比训练模型更直接。模型没有执行能力，需要的是Tool。任务流程复杂，需要的是Agent。
只有当问题确实来自模型自身，比如特定任务长期无法稳定遵循指令、特定领域行为模式始终不理想，才考虑微调。
如果是更系统性的领域知识缺失或数据分布问题，才可能进一步考虑继续训练。
训练模型是Agent工程化中的一种优化手段，只在模型本身成为瓶颈时才有必要。
把这些能力组装起来
把这些能力放在一起，会发现AI Agent并不存在一条"升级路线"。
更像是两个方向同时建设。
能力方向上，从模型出发，依次是Prompt和Context工程、RAG、Tool、Workflow、Agent。Multi-Agent是更复杂的协作形式。
生产能力方向上，先有Evaluation和Observability提供反馈能力，再加上Guardrails、Security、权限控制、Human-in-the-loop等防护层，最后是成本、延迟控制和持续优化。
微调和继续训练围绕模型本身，用来解决模型能力不足的问题。
AI Agent工程化真正的目标是稳定可控，便于评估与维护。
这也是为什么真正成熟的Agent，未必拥有最复杂的架构。一个简单的模型，加上准确的知识检索、清晰的工具定义、合理的Workflow、严格的权限控制和完整的评估闭环，已经可以完成很多有价值的生产任务。
Agent真正的竞争力，在于能不能在可接受的成本和风险下，持续把事情做对。
模型决定Agent能做什么。工程决定Agent能不能稳定做到。大部分项目真正卡住的地方，就在这里。
