把 22 个模式组合成一个可上线 Agent 系统

前面 22 章，我们讲了很多模式。

提示链、路由、并行化、反思、工具、规划、记忆、RAG、多智能体、MCP、A2A、安全、评估。

但真正做项目时，不能把它们当成孤立概念。

Agent 不是“加一个大模型”。

Agent 是一套能完成任务的工程系统。

这一章只解决一个问题：这些模式到底怎么组合，才能变成可上线系统？

1. 先把 22 个模式看成一个工具箱

单个模式有价值。

组合起来才有杀伤力。

一个真实 Agent 系统，通常需要同时解决五类问题。

第一类：任务怎么拆。

复杂目标不能直接扔给模型。要用提示链拆步骤，用路由选路径，用规划定顺序，用并行化提效率。

第二类：能力怎么接。

模型本身不能查订单、不能读数据库、不能访问内部文档。要靠工具调用、RAG、MCP、A2A，把外部能力接进来。

第三类：状态怎么留。

多轮任务最怕丢上下文。要靠记忆、任务状态、轨迹日志，让系统知道做到哪一步。

第四类：质量怎么控。

反思、学习适应、评估监控，解决的是“做完以后怎么知道做得好不好”。

第五类：风险怎么管。

异常恢复、护栏、人类审批、资源控制，解决的是“出事以后能不能兜住”。

2. 真正的 Agent 架构，不是一个大 Prompt

很多项目失败，是因为架构太粗。

用户问题进来，直接塞给大模型。

模型回答看似完整，实际没有数据、没有权限边界、没有轨迹、没有评估。

这不是 Agent。

这只是聊天。

生产级 Agent 至少要分层。

入口层负责接收请求。

编排层负责判断任务、拆解计划、安排优先级。

能力层负责调用知识库、业务接口、外部工具和其他 Agent。

状态层负责保存上下文、任务进度和完整轨迹。

保障层负责安全、审批、异常恢复、监控和成本控制。

这几层分清楚，系统才好维护。

出了问题，也知道该查哪里。

3. 推荐落地顺序：先闭环，再扩展

不要一开始就做多智能体。

不要一开始就接几十个工具。

不要一开始就追求全自动。

正确做法是：先做一个小闭环。

第一步，明确目标。

用户要什么？系统输出什么？什么结果算成功？

第二步，接入知识。

先用 RAG 解决“答得准”。内部文档、FAQ、规范、日志说明，都要有来源。

第三步，接入工具。

让 Agent 从“会说”变成“会做”。但工具必须有白名单、参数校验和权限控制。

第四步，加入状态。

把当前任务进度、用户上下文、工具返回结果、失败原因都保存下来。

第五步，加生产保障。

高风险动作要审批。异常要恢复。输出要校验。成本要监控。

第六步，再扩展复杂能力。

当单体 Agent 已经稳定，再考虑多 Agent、MCP、A2A、探索发现。

4. 案例：企业智能客服 Agent

只看一个例子。

用户问：我的退款为什么还没到账？

如果只是普通大模型，它只能猜。

如果是 Agent，它会按流程做事。

第一步，路由。

系统判断这是退款问题，不是闲聊，也不是产品咨询。

第二步，RAG。

检索退款规则、到账时效、异常处理说明。

第三步，工具调用。

查询订单状态、退款单状态、支付渠道状态。

第四步，记忆。

记录本次用户咨询、订单号、查询结果、是否已转人工。

第五步，护栏。

如果用户要求越权退款，系统拒绝。

如果要修改退款金额，必须走人工审批。

第六步，生成答复。

答复必须基于真实查询结果和规则来源，不能编。

第七步，评估监控。

记录是否命中知识库、是否调用正确工具、用户是否追问、是否转人工。

这就是模式组合。

不是某一个模式厉害。

而是多个模式一起，让系统变得可靠。

5. 源码级看，组合模式其实是状态机

从工程视角看，Agent 系统不是玄学。

它本质上是一个状态机。

每一步都有输入、输出、状态和边界。

核心逻辑可以这样理解：

接收用户目标，生成任务上下文。

路由判断任务类型，选择执行路径。

规划器拆解步骤，生成可执行计划。

执行器调用 RAG、工具、MCP 服务或其他 Agent。

状态管理器保存每一步结果。

反思器或评估器检查结果质量。

护栏判断是否允许继续。

高风险动作进入 HITL 审批。

最终输出答案，并记录完整轨迹。

所以开发 Agent，不是只写 Prompt。

更重要的是写清楚状态流转、工具契约、异常路径和评估指标。

6. 上线前，至少问清楚这 8 件事

目标不清，Agent 就会乱跑。

数据不准，Agent 就会胡说。

工具没边界，Agent 就可能越权。

状态不落库，失败后就无法恢复。

没有护栏，就挡不住提示注入和危险请求。

没有审批，高风险动作就不能上线。

没有评估，就不知道改动是变好了还是变坏了。

没有成本控制，系统一火，账单先爆。

7. 未来趋势：从“会聊天”到“会协作”

未来的 Agent，不会只是一个聊天框。

它会更像一个团队成员。

能接企业工具。

能记住任务进度。

能调用专业 Agent。

能被监控和评估。

能在关键动作前请求审批。

但方向再热，也不能忘记工程底线。

Agent 越自主，越需要边界。

能力越强，越需要审计。

流程越复杂，越需要可观测。

不是让 AI 放飞自我。

而是让 AI 在规则内稳定干活。

8. 最后总结

这套专栏的核心，不是让你背 22 个名词。

而是建立一个判断框架。

遇到一个 AI 需求，先问四个问题：

它只是问答，还是要完成任务？

它需要查资料，还是需要调用工具？

它需要一次性完成，还是长期持续执行？

它有没有权限、安全、成本、质量风险？

答案不同，架构就不同。

简单问答，用 LLM。

需要知识，用 RAG。

需要行动，用 Tool Use。

任务复杂，用 Planning。

需要协作，用 Multi-Agent。

要上线，就必须加 Guardrails、HITL、Evaluation、Monitoring。

真正值钱的能力，不是会问大模型。

而是会把大模型，设计成一个可用、可控、可上线的智能体系统。