一、问题变化：Agent 把“概率性”带进了业务执行链
Agent 架构真正要解决的问题不是“怎样让模型更聪明”，而是：
怎样把一个概率性的决策者，放进一个确定、可靠、可验证的业务系统中。
从这个问题出发，生产级 Agent 有三个核心设计对象：
- 信息：模型依据什么做判断？
- 执行：模型的判断怎样安全、可靠地变成真实动作？
- 验证：系统怎样知道最终做对了，而且没有越界？
也就是：
Context & State → Reliable Execution → Verification & Governance
例如做一个代码迁移 Agent：
- 首先要让它按需获得相关代码、SDK 文档和项目规范，同时把迁移进度保存在模型窗口之外；
- 然后允许它自主搜索代码、修改文件和运行测试，但只能通过受控Tool 和 Sandbox 执行，并能从中断处恢复；
- 最后不能由 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”这样的角色出发。
真正应该判断的是：
- 子任务能不能独立完成；
- 结果能不能独立验证；
- 大量探索过程是否有必要进入主 Context；
- 是否存在清晰的状态读写边界。
例如子 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 更强调：
- 可发现：模型知道什么时候应该使用；
- 契约清晰：参数、返回值和边界明确；
- 错误可理解：失败结果能够指导下一步修正；
- 副作用明确：读操作和写操作有清晰区别；
- 安全可控：危险操作经过权限、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
即：
- Outcome：事情到底有没有做成？
- Constraint：做事过程中有没有违反规则？
代码迁移 Agent 可以自主决定先搜索哪个模块、先修改哪个文件，但最终必须满足：
编译通过 + 测试通过 + Diff 合法 + 没有修改禁止文件。
Trace：先把事实记录下来
Agent 的错误很多不会产生 Exception，因此必须记录完整决策链：
Goal → Context → Decision → Tool → Observation → Replan → Outcome
Trace 的价值不只是排查异常。
它同时是：
Debug、Eval、Audit、Replay、优化
的事实基础。
Eval：判断 Agent 到底有没有变好
Eval 应该覆盖四个维度：
- 效果性：任务是否真正完成；
- 稳定性：同类任务能否持续完成；
- 安全可靠性：有没有越权，失败是否可恢复；
- 工程效率：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：
遗漏约束 → Context
选错工具 → Tool Contract
中断无法恢复 → Checkpoint
重复操作 → Idempotency
结果不可交付 → Verification / Eval
越权操作 → 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 技术是否值得长期投入，可以问四个问题：
- 它解决的是真实生产 Failure Mode，还是只是 Demo 更漂亮？
- 它能否进入现有的权限、日志、配置、部署和治理体系？
- 它带来的改善能否通过Trace 和 Eval证明？
- 即使明天更换模型和 Framework，这项能力是否依然存在？
这就是所谓技术能力的半衰期。
架构师真正应该积累的不是：
我会多少 Agent Framework。
而是：
我能不能把概率性的智能能力，工程化成一个长期可靠运行的业务系统。
