Agent 开发架构：从增强型 LLM 到可运维的自治系统

Agent 开发架构：从增强型 LLM 到可运维的自治系统

过去一年里，Agent 从一个容易被营销滥用的词，逐渐沉淀成一套工程问题：如何让大模型在明确边界内感知上下文、选择工具、执行动作、接收反馈，并在失败时恢复？真正困难的地方往往不在“让模型说得像人”，而在把模型放进一个可测试、可观测、可控的运行系统里。

本文把 Agent 开发架构拆成几个层次：基础定义、核心组件、编排模式、多 Agent 取舍、上下文与工具协议、安全治理，以及一套可落地的参考架构。

1. 先定义：Workflow 和 Agent 不是一回事

在工程实践中，建议把“Agentic system”分成两类：

• Workflow：由代码预先规定路径，大模型和工具只是其中的节点。例如“先抽取字段，再校验，再生成报告”。
• Agent：模型动态决定下一步做什么、调用哪些工具、何时停止。例如“修复一个未知代码仓库里的 bug”，它需要不断观察测试结果、搜索文件、修改代码并重试。

Anthropic 在《Building effective agents》中给出的经验很值得作为架构原则：从最简单方案开始，只有当任务确实需要弹性决策、多步反馈或开放式探索时，才引入 Agent。原因很朴素：Agent 会用更多模型调用、更多工具执行和更复杂状态，成本、延迟、调试难度都会上升。

一个实用判断标准是：

• 如果任务路径稳定、输入类型清晰，优先用 workflow。
• 如果任务步骤不可预知、需要模型根据环境反馈调整策略，再考虑 agent。
• 如果单次 LLM + RAG + 示例就能解决，不要为了“架构感”强行上 Agent。

2. Agent 的核心组件

一个生产级 Agent 通常不是“一个 prompt”，而是以下组件的组合。

2.1 模型与指令层

模型负责推理、规划、生成结构化参数。指令层定义角色、任务边界、输出格式、停止条件和工具使用规则。越接近生产，指令越应该像接口契约，而不是散文。

建议把系统指令分成四类：

• 身份与目标：这个 Agent 负责什么，不负责什么。
• 决策策略：什么时候调用工具，什么时候询问用户，什么时候拒绝。
• 输出契约：返回 JSON、Markdown、代码补丁还是用户消息。
• 约束条件：权限、预算、最大迭代轮次、安全边界。

2.2 工具层

工具是 Agent 与外部世界连接的手。工具可以是函数、HTTP API、数据库查询、浏览器、文件系统、代码执行器、搜索引擎或企业内部工作流。

工具设计是 Agent 架构中最容易被低估的部分。一个好工具应该具备：

• 清晰的名称和职责，不要一个工具塞进太多动作。
• 明确的输入 schema 和输出 schema。
• 可恢复的错误信息，而不是只返回“失败”。
• 幂等性或事务边界，尤其是涉及付款、删除、发邮件、改生产数据时。
• 权限分级，高风险工具默认需要确认。

OpenAI Agents SDK 把 function tools、MCP server tool calling、guardrails、sessions、handoffs、tracing 都放进同一个运行模型里，这反映了一个趋势：工具不再只是“函数调用”，而是 Agent runtime 的核心边界。

2.3 上下文与记忆层

Agent 的质量很大程度上取决于它“看见了什么”。上下文通常包括：

• 当前用户输入。
• 对话历史。
• 检索到的文档、代码、数据。
• 工具调用结果。
• 中长期记忆，如用户偏好、项目约束、历史决策。
• 当前任务状态，如计划、待办、失败原因、已尝试路径。

上下文不是越多越好。LangChain 的多 Agent 文档强调了“context engineering”：决定每个 Agent 看到哪些信息。上下文过多会增加成本、稀释注意力，还可能把无关信息变成错误决策依据。

生产系统里常见的上下文策略包括：

• 短期状态：保存在 session 或 run state 中，用于当前任务。
• 长期记忆：进入数据库、向量库或用户画像系统，需要写入过滤和隐私治理。
• 检索增强：按需查询知识库、代码库、业务数据。
• 摘要压缩：长任务中把历史步骤压成可追踪摘要。
• 隔离上下文：多 Agent 架构中让子 Agent 只拿到完成任务所需的信息。

2.4 编排与运行时

Agent runtime 负责循环执行：

1. 接收目标和上下文。
2. 调用模型生成下一步决策。
3. 校验工具参数和权限。
4. 执行工具。
5. 把观察结果写回状态。
6. 判断继续、暂停、请求人工输入或结束。

这看似简单，但生产级 runtime 还要处理超时、重试、取消、并发、限流、成本预算、状态持久化、日志、trace、回放和恢复。

Google ADK、OpenAI Agents SDK 等框架都在把这些能力标准化：Agent 不只是模型调用，而是一个可运行、可调试、可部署的长生命周期任务。

3. 常见编排模式

不要一上来就多 Agent。大多数系统可以从以下模式逐步演进。

3.1 Prompt Chaining：提示链

把任务拆成固定步骤，每一步的输出作为下一步输入。例如：

1. 提取需求。
2. 生成方案。
3. 校验方案。
4. 输出最终文档。

适合路径稳定、每步目标清晰的任务。优点是可控、易调试；缺点是弹性不足。

3.2 Routing：路由

先判断输入类型，再交给不同流程或专用 Agent。例如客服系统把问题分到退款、物流、技术支持、投诉升级。

适合输入类别明显、不同类别需要不同工具和策略的场景。路由可以用传统分类器，也可以用小模型完成。

3.3 Parallelization：并行化

把任务拆成可并行子任务，最后聚合结果。例如安全审查中让多个检查器分别看权限、注入、依赖漏洞和日志泄露。

适合需要多视角、可独立计算、对延迟敏感的任务。注意聚合器必须有明确评价标准，否则只是把多个不确定答案拼在一起。

3.4 Orchestrator-Workers：编排器-工作器

一个中心编排器动态拆解任务，分配给多个 worker，再综合结果。它适合子任务数量和类型难以预先写死的场景，比如代码修改、复杂研究、跨系统排障。

这种模式的关键是：编排器要有足够强的任务分解能力，worker 要有清晰职责，最终合成要能追溯每个结论来自哪里。

3.5 Evaluator-Optimizer：评价-优化循环

一个模型生成结果，另一个模型或规则系统评价并提出修改意见，循环直到达标或触发停止条件。

适合有明确质量标准的任务，如翻译润色、代码审查、研究报告、测试生成。它的价值不在“多调用几次”，而在评价标准是否可验证。

4. 多 Agent 架构：什么时候值得用

多 Agent 的吸引力很强，但它也会带来更多延迟、成本和状态复杂度。一般只有在以下情况值得引入：

• 单个 Agent 工具太多，容易选错工具。
• 不同领域需要不同上下文和专用能力。
• 任务天然可并行。
• 不同团队需要独立维护不同能力边界。
• 需要角色隔离，例如执行者、审查者、审批者分离。

常见多 Agent 模式包括：

• Subagents：主 Agent 把子 Agent 当工具调用，集中控制强，上下文隔离好。
• Handoffs：Agent 之间转交控制权，适合多轮对话中用户直接和不同专家交互。
• Router：先分类，再调用一个或多个专用 Agent，适合多领域并行任务。
• Skills：单 Agent 保持控制，只在需要时加载专用知识、流程或工具说明。
• Custom Graph Workflow：用图结构显式描述状态流转，把确定性逻辑和模型决策混合起来。

一个很实用的经验是：如果只是想复用知识，优先考虑 skills 或工具；如果需要并行和上下文隔离，再考虑 subagents/router；如果用户需要与不同专家连续交互，再考虑 handoffs。

5. MCP：Agent 工具生态的标准化接口

Model Context Protocol（MCP）试图解决一个核心问题：每个 Agent 都要接数据库、文件、SaaS、搜索、企业 API，如果每个宿主应用都重复做一套集成，生态会非常碎。

MCP 使用标准协议把 AI 应用和外部系统连接起来。官方规范中，MCP 把通信参与者分为：

• Host：发起连接的 LLM 应用。
• Client：Host 内部的连接器。
• Server：提供上下文和能力的外部服务。

Server 可以暴露三类能力：

• Resources：可读取的数据和上下文。
• Prompts：可复用的模板消息或工作流。
• Tools：可由模型调用的函数或动作。

对 Agent 架构来说，MCP 的意义不是“换一种 RPC”，而是把工具、数据和提示模板变成可组合、可发现、可治理的边界。未来企业内部很可能会出现一批标准 MCP server：代码库、工单系统、CRM、数据仓库、BI、权限系统、文档库等。

但 MCP 也会放大安全问题。规范明确提醒：工具可能代表任意代码执行路径，数据访问和工具调用必须有用户授权、权限控制和清晰 UI。

6. 安全、治理与人类介入

Agent 的风险来自“会行动”。一个普通聊天机器人说错话，影响通常停留在信息层；一个接入邮箱、支付、生产数据库和部署系统的 Agent 出错，影响会进入真实世界。

生产架构中至少要有以下防线：

• 输入防护：识别 prompt injection、越权请求、恶意文件和不可信网页内容。
• 工具权限：按工具、资源、用户、环境划分权限。
• 动作确认：高风险动作必须 human-in-the-loop。
• 输出校验：结构化 schema 校验、业务规则校验、安全策略校验。
• 沙箱执行：代码、浏览器、文件操作尽量在隔离环境中运行。
• 审计日志：记录模型决策、工具调用、参数、结果、人工确认。
• 停止条件：最大轮次、预算上限、失败次数、时间限制。

Human-in-the-loop 不是“让人兜底”这么简单，而是要设计清楚哪些节点需要人工判断：目标确认、权限授权、不可逆操作、低置信度结果、策略冲突、外部副作用。

7. 可观测性与评估

Agent 系统不能只看最终回答。它的可观测性至少要覆盖：

• 每一次模型调用的输入、输出、token、耗时、成本。
• 每一次工具调用的参数、返回值、错误、重试。
• 当前计划、状态迁移和停止原因。
• 检索命中文档和引用来源。
• guardrail 是否触发。
• 人工介入点和审批结果。

评估也要从“答案是否好看”转向“任务是否可靠完成”。建议建立四类 eval：

• 离线样例集：覆盖典型输入、边界输入和攻击输入。
• 工具调用正确性：是否选对工具、参数是否正确、是否遵守权限。
• 端到端任务成功率：如工单解决、代码测试通过、报告可审计。
• 回归评估：prompt、模型、工具 schema 改动后是否破坏旧能力。

如果你的 Agent 能重放一次失败任务，并清楚看到它在哪一步误判，那么这个系统才真正进入可工程化阶段。

8. 一套参考架构

下面是一套面向生产的通用 Agent 架构，可按场景裁剪。

这套架构的核心思想是：模型只负责智能决策，不直接拥有无限权限；工具、上下文、权限、评估、审计都在 runtime 周围形成工程边界。

9. 落地路线图

阶段一：增强型 LLM

先做一个单模型应用，接入 RAG、少量工具、结构化输出和基本日志。目标是验证任务是否真的需要多步行动。

交付物：

• 清晰系统 prompt。
• 2-5 个高价值工具。
• 一组离线测试样例。
• 基础 trace 和成本统计。

阶段二：受控 Workflow

把稳定路径固化为 workflow，例如“分类 -> 检索 -> 生成 -> 校验 -> 输出”。在关键节点加入规则校验和人工确认。

交付物：

• 状态机或 DAG。
• 中间结果 schema。
• 每一步可单独测试。
• 失败重试和降级策略。

阶段三：单 Agent Loop

当任务步骤不可预知时，引入 Agent loop，让模型根据观察结果决定下一步。此时必须加入最大轮次、预算、工具权限和停止条件。

交付物：

• Agent runtime。
• 工具调用审计。
• session/state 持久化。
• 高风险动作确认。

阶段四：多 Agent 或图工作流

只有在上下文隔离、并行执行或团队边界确实需要时，再引入多 Agent。优先显式建模任务图，不要让 Agent 之间自由聊天到失控。

交付物：

• 主 Agent 与子 Agent 职责边界。
• 上下文传递规则。
• 跨 Agent trace。
• 端到端 eval。

10. 常见反模式

• 为了 Agent 而 Agent：固定流程硬做成自治循环，成本变高且更难调试。
• 工具过大：一个工具既查询又写入又发送通知，模型一旦选错影响巨大。
• 上下文全塞进去：模型被无关内容淹没，成本和误判同时上升。
• 没有停止条件：失败时无限重试，烧钱还可能造成副作用。
• 缺少回放能力：线上出错后只能猜 prompt 哪里坏了。
• 把安全交给 prompt：仅靠一句“不要做危险操作”是不够的。
• 过早多 Agent：多个 Agent 互相转述，错误和 token 一起膨胀。

结语

Agent 架构的本质不是“让模型更自由”，而是给模型一套可靠的行动系统：它知道目标，能看见必要上下文，能调用被良好设计的工具，能从环境反馈中修正路线，也能在风险升高时停下来请求人类判断。

最稳妥的路线是从简单开始：增强型 LLM、受控 workflow、单 Agent loop，再到多 Agent 和图工作流。每引入一层复杂度，都应该换来可测量的任务成功率提升，而不是只换来一张更漂亮的架构图。

参考资料

• Anthropic Engineering: Building effective agents
• OpenAI: OpenAI Agents SDK
• Google: Agent Development Kit documentation
• LangChain Docs: Multi-agent systems
• Model Context Protocol: What is MCP?
• Model Context Protocol: Specification 2025-06-18
• arXiv: Large Language Model based Multi-Agents: A Survey of Progress and Challenges
• arXiv: A Survey on the Memory Mechanism of Large Language Model based Agents
• arXiv: A Survey on Autonomy-Induced Security Risks in Large Model-Based Agents