一、问题变化：Agent 把“概率性”带进了业务执行链

Agent 架构真正要解决的问题不是“怎样让模型更聪明”，而是：

怎样把一个概率性的决策者，放进一个确定、可靠、可验证的业务系统中。

从这个问题出发，生产级 Agent 有三个核心设计对象：

1. 信息：模型依据什么做判断？
2. 执行：模型的判断怎样安全、可靠地变成真实动作？
3. 验证：系统怎样知道最终做对了，而且没有越界？

也就是：

Context & State → Reliable Execution → Verification & Governance

例如做一个代码迁移 Agent：

1. 首先要让它按需获得相关代码、SDK 文档和项目规范，同时把迁移进度保存在模型窗口之外；
2. 然后允许它自主搜索代码、修改文件和运行测试，但只能通过受控Tool 和 Sandbox 执行，并能从中断处恢复；
3. 最后不能由 Agent 自己宣布“迁移完成”，而要通过编译、测试、Git Diff 和权限规则确定结果是否真的可交付。

这三个问题构成后续所有 Agent 架构设计的主线。

二、核心设计：把概率性限制在应该存在的位置

1. 信息层：Context 决定模型怎么判断，State 保证系统记得事实

Agent 的每一次决策，本质上都是：

基于当前 Context，对下一步行动进行概率性判断。

因此很多所谓的模型错误，实际上首先应该检查 Context。

典型问题包括：

• 大量 Tool 输出淹没了真正目标；
• 过期信息仍然存在于上下文；
• 压缩过程中丢失关键约束；
• 大量探索过程污染主任务；
• 任务进度只存在聊天记录中。

解决这些问题，需要首先区分Context 和 State。

Context：当前决策需要的信息

Context 应该被理解成：

模型当前推理的运行时工作集。

模型窗口只保留当前决策需要的目标、约束、证据和最近执行结果。

代码、日志、大文件、历史资料等放在窗口之外，通过检索按需加载。

所以 Context Engineering 的目标不是：

塞进去更多信息。

而是：

在当前决策点提供最相关、最可靠的信息。

State：系统必须可靠保存的事实

任务目标、执行进度、已经完成的操作、审批状态、失败记录和最终产物，不能只存在 Context 中，而应该持久化。

尤其需要区分：

• Task：用户希望完成什么；
• ExecutionAttempt：系统这一次是怎样尝试完成它的。

这一区分是 Retry、恢复和幂等的基础。

因此：

Context 解决“模型现在应该知道什么”，State 解决“系统必须记住什么”。

Multi-Agent 也是一种边界设计

从这个角度看，Multi-Agent 也不应该首先从“产品经理 Agent、开发 Agent、测试 Agent”这样的角色出发。

真正应该判断的是：

1. 子任务能不能独立完成；
2. 结果能不能独立验证；
3. 大量探索过程是否有必要进入主 Context；
4. 是否存在清晰的状态读写边界。

例如子 Agent 搜索 200 个文件，最终只向主 Agent返回：

“三个模块受影响，以及对应证据。”

那么拆分可以有效隔离 Context。

反过来，如果多个 Agent 需要频繁修改同一个状态，拆分反而会引入一致性和责任归属问题。

所以 Multi-Agent 的核心价值首先是：

上下文隔离 + 独立并行 + 清晰边界。

2. 执行层：模型负责判断，确定性系统负责执行边界

模型获得正确的信息以后，就会产生下一步行动。

此时 Agent 架构最重要的原则出现了：

AI 负责不确定性，代码负责确定性边界。

模型可以负责：

理解、Planning、Tool Selection、判断、Replan。

但下面这些事情不能由模型决定：

Permission、Transaction、Quota、Idempotency、Resource Limit、Approval、Audit。

因此一次真实操作应该经过：

模型提出动作 → 领域规则判断 → 权限校验 → 执行器产生副作用 → 验证结果

Agent 可以决定：

“我想修改这个文件。”

但系统决定：

“你有没有权限修改、能修改哪些文件、修改以后怎样验证。”

这就是 Agent 的Decision Boundary。

Tool：概率性决策与确定性系统之间的契约

Tool 是这条边界最重要的接口。

传统 API 的消费者通常是确定性程序，而 Tool 面对的是概率性调用者，因此 Tool 需要比普通 API 更强调：

1. 可发现：模型知道什么时候应该使用；
2. 契约清晰：参数、返回值和边界明确；
3. 错误可理解：失败结果能够指导下一步修正；
4. 副作用明确：读操作和写操作有清晰区别；
5. 安全可控：危险操作经过权限、Sandbox 或 Approval。

所以 Tool 设计追求的不是数量，而是：

语义正交、边界清晰、行为可预测。

Failure：不仅要处理执行失败，还要处理决策失败

传统系统主要处理：

Network Timeout、DB Down、Service Crash。

Agent 又增加了：

Decision Failure。

例如：

选错 Tool → 参数错误 → Tool 成功执行 → 错误理解结果 → 错误 Replan

整个过程可能全部 HTTP 200，但业务已经错误。

因此 Agent Failure Recovery 不能简单等于Retry × 3，而应该区分：

• Retry：执行路径正确，只是临时故障；
• Replan：当前决策路径错误；
• Fallback：当前模型或 Tool 不适合；
• Human Handoff：风险超过自动化边界；
• Terminate：超过循环、成本或安全边界。

这里的目标不是让 Agent 永远不失败，而是：

错误可限制、执行可恢复。

Durable Execution：长任务必须能够从中断处继续

只要 Agent 开始执行分钟级甚至小时级任务，就必须假设：

中断一定会发生。

因此：

Task → Step → External Action → Result

需要持续持久化。

Checkpoint 记录执行位置，Event Log 记录已经发生的事实，Idempotency 防止恢复以后重复产生副作用，必要时通过 Compensation 撤销已经完成的动作。

所以可靠 Agent 不是“不失败”，而是：

失败以后仍然知道做过什么，并能够安全继续。

3. 验证层：执行路径可以不确定，但结果必须可验证

Agent 可以动态选择执行路径，因此传统的：

Path Correctness

不再足够。

同一个任务可能通过不同路径完成，只要最终业务结果正确，并且整个过程没有违反系统约束，都可以认为任务成功。

因此 Agent 正确性应该重点验证：

Outcome Correctness + Constraint Correctness

即：

1. Outcome：事情到底有没有做成？
2. Constraint：做事过程中有没有违反规则？

代码迁移 Agent 可以自主决定先搜索哪个模块、先修改哪个文件，但最终必须满足：

编译通过 + 测试通过 + Diff 合法 + 没有修改禁止文件。

Trace：先把事实记录下来

Agent 的错误很多不会产生 Exception，因此必须记录完整决策链：

Goal → Context → Decision → Tool → Observation → Replan → Outcome

Trace 的价值不只是排查异常。

它同时是：

Debug、Eval、Audit、Replay、优化

的事实基础。

Eval：判断 Agent 到底有没有变好

Eval 应该覆盖四个维度：

1. 效果性：任务是否真正完成；
2. 稳定性：同类任务能否持续完成；
3. 安全可靠性：有没有越权，失败是否可恢复；
4. 工程效率：Latency、Token、Tool Call 和人工成本是否合理。

真正重要的是形成持续闭环：

生产 Trace → 失败样本 → Eval Dataset → 回归测试 → 发布 → 线上 Trace → 新失败样本

这样模型升级、Prompt 修改、Tool 调整和 Context 策略变化才具有真正的工程发布机制。

Safety：控制的是 Failure Radius

安全不能依赖：

“请谨慎操作生产环境。”

真正的安全来自：

Permission + Sandbox + Approval + Audit + Rollback

所以生产 Agent 的安全目标并不是“模型绝不犯错”，而是：

即使判断错误，也不能突破确定性边界；即使产生影响，也必须可发现、可限制、可追责、可恢复。

三、工程落地：不要先造 Agent 平台，先跑一个闭环

理解上述架构以后，真正落地时反而应该克制。更合理的方法是：

从一个目标明确、结果可验证、失败可回滚的任务开始。

仍然以代码迁移 Agent 为例，第一版只支持：

一种固定 SDK 的自动迁移。

架构只需要建立三个边界。

1. 任务边界

明确：迁移什么 → 输入范围 → 完成条件。解决： Agent 到底要完成什么？

2. 执行边界

第一版使用：

Single Agent + 少量 Tool + External State + Sandbox + Checkpoint

解决：

Agent 可以做什么，以及失败后怎么继续？

3. 验证边界

建立：

Test + Git Diff + Trace + 初始 Eval Dataset + Human Review

解决：

怎么证明 Agent 做对了？

然后观察生产中的真实 Failure Mode：

1. 遗漏约束 → Context

2. 选错工具 → Tool Contract

3. 中断无法恢复 → Checkpoint

4. 重复操作 → Idempotency

5. 结果不可交付 → Verification / Eval

6. 越权操作 → Permission / Sandbox / Approval

架构由此沿着真实问题生长：

Failure Mode → Architecture Capability

当然，权限、审计、数据边界和回滚能力属于生产底线，不能等事故发生以后再建设。

四、长期能力：架构师应该沉淀什么

到这里再回头看 Agent 技术，就会发现很多今天热门的名词其实处于不同层次。

LLM、Agent SDK、Framework、编排语法可能快速变化。

而下面这些能力变化会慢很多：

Context Management

Tool Contract

State Machine

Checkpoint / Durable Execution

Idempotency

Permission / Sandbox

Trace

Eval

Audit / Failure Recovery

因此判断一个 Agent 技术是否值得长期投入，可以问四个问题：

1. 它解决的是真实生产 Failure Mode，还是只是 Demo 更漂亮？
2. 它能否进入现有的权限、日志、配置、部署和治理体系？
3. 它带来的改善能否通过Trace 和 Eval证明？
4. 即使明天更换模型和 Framework，这项能力是否依然存在？

这就是所谓技术能力的半衰期。

架构师真正应该积累的不是：

我会多少 Agent Framework。

而是：

我能不能把概率性的智能能力，工程化成一个长期可靠运行的业务系统。