一、问题变化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 → OutcomeTrace 的价值不只是排查异常。它同时是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 ManagementTool ContractState MachineCheckpoint / Durable ExecutionIdempotencyPermission / SandboxTraceEvalAudit / Failure Recovery因此判断一个 Agent 技术是否值得长期投入可以问四个问题它解决的是真实生产 Failure Mode还是只是 Demo 更漂亮它能否进入现有的权限、日志、配置、部署和治理体系它带来的改善能否通过Trace 和 Eval证明即使明天更换模型和 Framework这项能力是否依然存在这就是所谓技术能力的半衰期。架构师真正应该积累的不是我会多少 Agent Framework。而是我能不能把概率性的智能能力工程化成一个长期可靠运行的业务系统。