AI Agent 任务编排引擎架构：从单循环到生产级编排的演进

一、为什么 Agent 不是一个 LLM 调用

第一版 Agent 几乎都是这样的——调一次 LLM，拿到结果就返回。这不是 Agent，这只是一个会说话的 HTTP 接口。生产级 Agent 必须具备四个能力：目标分解、记忆累积、工具调用、自我反思。任何一个缺失，做出来的都是"看上去聪明"的玩具。

从工程视角看，Agent 本质是一个由 LLM 驱动的分布式状态机。状态包括目标、上下文、工具结果、反思历史；转移由 LLM 决策；副作用通过工具层施加。这一视角决定了所有架构决策：状态持久化、可重入、可恢复、可观测。

graph LR
    A[目标 Goal] --> B{LLM 决策}
    B -->|Plan| C[任务分解]
    B -->|Act| D[执行工具]
    B -->|Reflect| E[反思重试]
    C --> B
    D --> B
    E --> B
    B -->|Done| F[返回结果]

二、核心架构：四层编排模型

经过三个版本迭代，我们把 Agent 引擎收敛为四层：规划层、记忆层、工具层、执行层。每一层有明确的边界、独立的可观测面、可独立替换的实现。层与层之间通过事件总线通信，而不是直接调用，从而获得异步、可回放、可降级的工程属性。

graph TB
    subgraph 引擎核心
        P[规划层
Plan / Replan / Reflect]
        M[记忆层
Short / Working / Long]
        T[工具层
MCP / Function / Plugin]
        E[执行层
Sandbox / Retry / Rollback]
    end
    B[事件总线
EventBus]
    P -.-> B
    M -.-> B
    T -.-> B
    E -.-> B
    OBS[可观测层
Trace / Metric / Log]
    B --> OBS

2.1 分层原则

每一层遵守三个原则：无状态优先（状态外置到记忆层）、幂等设计（重试安全）、失败可见（任何异常必须上报到可观测层）。这些原则不是口号，而是从生产事故里长出来的教训——比如一次因记忆层未持久化导致重复扣款的事件，直接催生了"无状态优先"原则。

三、规划层：Plan / Replan / 反思机制

规划层是 Agent 的"大脑"，决定了它能不能从"会说话"变成"会做事"。我们经历了三代演进：单轮决策 → Plan-and-Execute → Reflexion。每一代都有明确的 trade-off，没有绝对最优。

3.1 Plan-and-Execute 模式

第一代是单轮 ReAct，发现任务稍微复杂就死循环——因为 LLM 在长上下文中容易"忘记自己在干嘛"。Plan-and-Execute 引入了先拆解再执行：Planner 一次性生成步骤列表，Executor 逐步执行。好处是上下文干净、可中断可恢复；坏处是 Planner 错了全盘皆输。

sequenceDiagram
    participant User
    participant Planner
    participant Executor
    participant Tool
    User->>Planner: 目标：调研某技术
    Planner->>Planner: 拆解为 5 步
    loop 步骤执行
        Executor->>Tool: 调用搜索/抓取/总结
        Tool-->>Executor: 结果
        Executor->>Executor: 校验结果
    end
    Executor->>Planner: 5 步全部完成
    Planner->>User: 综合输出

3.2 Reflexion 反思机制

Plan-and-Execute 的硬伤是 Planner 不可信。第二代引入 Reflexion——执行后让 LLM 反思这次动作是否合理，失败时把反思结果写入记忆，下一轮 Planner 在新上下文中重做决策。这让 Agent 有了"试错-学习"的雏形。

graph LR
    A[执行动作] --> B{是否成功}
    B -->|是| C[继续下一步]
    B -->|否| D[LLM 反思]
    D --> E[写入反思记忆]
    E --> F[触发 Replan]
    F --> A

3.3 trade-off 取舍

反思不是免费的。每次反思都是一次 LLM 调用，会拉高延迟和成本。生产上必须限制：反思次数上限（建议 3 次）、反思触发条件（仅在工具失败 / 结果校验失败时）、反思记忆压缩（避免无限膨胀）。否则 Agent 会陷入"反思地狱"——比死循环更隐蔽，token 烧得更快。

四、记忆层：短期 / 工作 / 长期三分

记忆是 Agent 与 LLM 的根本差异。LLM 只有上下文窗口（且每次调用独立），Agent 必须有跨调用、跨会话、跨用户的记忆。我们把记忆分成三层，每层对应不同的存储介质和生命周期。

graph TB
    subgraph 记忆三层
        S[短期记忆
当前会话上下文]
        W[工作记忆
当前任务进度]
        L[长期记忆
用户偏好/历史经验]
    end
    S -->|追加| W
    W -->|提炼| L
    L -->|召回| S

4.1 短期记忆（Short-Term）

短期记忆就是 LLM 的上下文窗口本身。生产上要做三件事：压缩（用 LLM 把长对话压成摘要）、截断（超长时丢弃最早消息）、优先级（系统指令 > 工具结果 > 用户输入）。这三个机制决定了 Agent 在长任务中的稳定性。

4.2 工作记忆（Working）

工作记忆是当前任务的结构化状态：计划步骤、已完成项、中间结果、失败重试次数。它必须持久化（Redis 或 PG），且支持原子更新。一次大任务可能跨分钟级、跨进程、跨实例，工作记忆就是"接力棒"。

4.3 长期记忆（Long-Term）

长期记忆存储跨任务、跨用户的经验与偏好。典型实现是向量数据库 + 结构化 KV 的组合：向量召回相似历史，KV 取精确事实。检索时要避免"被陈旧记忆带偏"——必须加时间衰减与可信度评分。

五、工具层：MCP 与 Function Call 的取舍

工具层是 Agent 的"手脚"，也是最容易失控的地方。Function Call 是 LLM 厂商提供的私有协议（OpenAI / Claude / Gemini 各有格式）；MCP（Model Context Protocol）是 Anthropic 2024 年推出的开放协议，目标是工具调用的标准化。我们的实践是短期兼容两家、长期押注 MCP。

5.1 Function Call 的痛点

Function Call 三个硬伤：厂商绑定（OpenAI 的 tool 格式 Claude 用不了）、描述不可控（工具描述质量直接决定调用成功率，但厂商不做校验）、无法跨进程（工具必须内嵌在 LLM 调用同进程）。这三个痛点在多模型、多团队、多语言的生产环境中会被无限放大。

5.2 MCP 协议的优势

MCP 解决了 Function Call 的全部三个问题：标准 JSON-RPC（模型无关）、工具描述 schema 校验（客户端校验）、独立进程部署（Tool Server 可远程）。代价是引入一次序列化/反序列化开销（<5ms），完全可接受。

graph LR
    A[Agent 引擎] -->|MCP 协议| B[Tool Server A]
    A -->|MCP 协议| C[Tool Server B]
    A -->|MCP 协议| D[Tool Server C]
    B --> E[数据库]
    C --> F[外部 API]
    D --> G[内部服务]

六、执行沙箱：权限、重试、回滚

Agent 一旦能调工具，就有了"破坏力"。生产事故告诉我们：沙箱不是可选项。我们经历了三次重大事故后，才把沙箱做到今天的程度。

6.1 权限分级

工具按风险分四级：L0 只读（搜索、查询）→ 无需授权；L1 写本地（创建文件）→ 自动；L2 写远端（调外部 API）→ 需用户授权；L3 不可逆（删数据、转账）→ 强制人工审核。LLM 在 L2/L3 操作前必须暂停，等待人确认。

graph TB
    L0[L0 只读
自动放行]
    L1[L1 写本地
自动放行]
    L2[L2 写远端
需用户授权]
    L3[L3 不可逆
强制人工审核]
    L0 --> L1 --> L2 --> L3

6.2 重试与回滚

所有工具调用必须幂等（用 idempotency_key）。幂等基础上才能安全重试。重试策略：指数退避 + 最大次数（建议 3 次）+ 失败告警。回滚分两种：补偿回滚（反向操作）和快照回滚（恢复到执行前状态）。L3 操作必须先打快照。

6.3 资源隔离

执行沙箱有三种实现：进程隔离（最简单，安全边界弱）、容器隔离（中等开销，强隔离）、WASM 隔离（极轻量，适合受限环境）。我们用容器做主沙箱，WASM 跑轻量工具（如数据转换），进程跑只读工具。

七、跨 Agent 协作：消息总线与状态同步

单个 Agent 能力有限，生产场景几乎都是多 Agent 协作——研究 Agent + 写作 Agent + 审核 Agent 串成流水线，每个 Agent 专注一件事。我们用消息总线 + 共享工作记忆的模式，把协作解耦为异步通信。

graph LR
    R[研究 Agent] -->|研究结果| BUS[消息总线]
    BUS --> W[写作 Agent]
    W -->|稿件| BUS
    BUS --> A[审核 Agent]
    A -->|审核意见| BUS
    BUS --> H[人类审核]
    SM[共享工作记忆]
    R -.-> SM
    W -.-> SM
    A -.-> SM

7.1 通信协议选型

总线选型核心是顺序保证 + 持久化 + 回溯能力。Kafka 太重，Redis Streams 不够持久，NATS 缺回溯。我们最终用 Pulsar（兼容 Kafka 协议 + 内置多租户），配合一个轻量级任务编排器做 Agent 状态机。

7.2 共享记忆与一致性

多 Agent 共享工作记忆时，写冲突是核心难题。两种模式：主从模式（一个 Agent 拥有写权限，其他只读）vs CRDT 模式（多 Agent 同时写，最终一致）。我们用主从模式——Agent 间通过消息通信而不是直接改共享记忆，避免冲突。

八、可观测性：让黑盒可调试

Agent 是出了名的"黑盒"——同一个问题，跑 10 次可能 10 次结果不同。生产环境必须把它变成"白盒"。我们做了三层可观测：Trace（决策链）、Metric（性能）、Log（原始事件）。

8.1 决策链 Trace

每一次 Agent 决策都要打决策点快照：当前任务、上下文摘要、LLM 原始输出、选择的工具、工具结果、反思内容。这是排查"为什么 Agent 做了这个决定"的唯一手段。生产事故 80% 来自这个 Trace 缺失。

sequenceDiagram
    participant A as Agent
    participant T as Trace
    participant O as 运维
    A->>T: step_1: Plan
    T-->>O: 实时可视化
    A->>T: step_2: Tool Call
    A->>T: step_3: Reflect
    O->>T: 查 Trace
    T-->>O: 完整决策链

8.2 成本可观测

Agent 的成本是指数级的——一次 20 步任务可能调 60 次 LLM。必须实时跟踪：每次调用的 token、单任务总成本、按用户/按工具/按场景的成本归因。生产上一个失控的 Agent 一晚上烧掉 5 位数 token 费的事故真实发生过。

九、降级与容错：生产级最后一公里

把 Agent 从"能跑"变成"敢上线"，差的就是降级策略。LLM 服务可能挂、工具可能失败、上下文可能超长——任何一环断了，Agent 必须能优雅降级，而不是抛错给用户。

9.1 三级降级

我们定义了三级降级：L1 切换模型（主模型挂则切备模型）、L2 简化任务（反思切不掉则放弃复杂功能）、L3 转人工（实在搞不定则把上下文打包转人工处理）。每一级都有独立的开关和告警。

graph TB
    A[Agent 任务] --> B{主模型可用?}
    B -->|是| C[正常执行]
    B -->|否| D{备模型可用?}
    D -->|是| E[切换备模型]
    D -->|否| F{可简化?}
    F -->|是| G[简化任务]
    F -->|否| H[转人工]

9.2 断路器与限流

外部工具挂掉时，必须有断路器——连续失败 N 次后自动熔断，避免雪崩。同样，每个 Agent 实例有并发限流，防止单用户抢占资源。LLM 调用层面也有限流，按 token/秒切分，避免被厂商限流。

十、演进路径与未来形态

Agent 架构还远未定型。当下我们看到的演进方向有三个：专业化分工（一个大 Agent → 一组专家 Agent）、工具市场（任何团队都能发布 MCP Server）、自演化能力（Agent 自己写代码改进自己）。每一个方向都充满不确定性，但工程路径已经清晰——分层、可观测、可降级。

10.1 从单体到微 Agent

第一代 Agent 什么都能干（其实什么都干不好）。未来的形态是微 Agent 协作——一个任务被拆给 N 个专家 Agent，每个 Agent 100 行 prompt、3 个工具、单一职责。这和服务化思路一脉相承。

10.2 工具市场生态

MCP 的真正威力不是协议本身，而是它催生的工具市场。当所有工具都按 MCP 标准化发布，工具的发现、授权、计费、安全审计都可以平台化。这是 Agent 时代的"App Store"。

10.3 自演化 Agent

终局是 Agent 自己写代码改进自己——根据线上失败案例自动生成修复 PR，根据用户反馈自动调整 prompt，根据工具市场动态引入新工具。这件事今天还像科幻，但分层架构已经把路铺好。

graph TB
    A[当前 Agent] --> B[收集线上失败]
    B --> C[自动生成修复 PR]
    C --> D[自部署]
    D --> A
    A --> E[用户反馈]
    E --> F[自动调整 Prompt]
    F --> A

📌 关键架构决策清单