Agent 架构与传统软件架构最大的区别，不是增加了 LLM、Memory、MCP 或 Multi-Agent，而是系统把一部分原本由代码确定的执行逻辑，交给了具有不确定性的模型动态决策。
这带来一个新的架构问题：
如何把"不确定的智能决策"，放进一个确定、可靠、可治理的工程系统？
这个问题可以沿着一条因果链拆成 5 个核心设计问题：
- 决策边界：既然 AI 可以决策，哪些事情可以让它决定？
- 架构取舍：边界确定后，到底应该给 Agent 多大的自主权？
- 正确性：自主权增加后，执行路径不再固定，怎么判断 Agent 做对了？
- 失败治理：既然 Agent 的判断可能错误，怎么控制错误及其影响范围？
- 可观测性：既然很多错误不会产生 Exception，怎么发现、定位和持续改进？
这五点不是并列能力，而是一条连续的架构推导：
Decision Boundary → Autonomy Trade-off → Correctness → Failure Control → Observability
可以用一个简单的企业报销 Agent 把这条链串起来。用户说："帮我把这次上海出差的费用报销掉。"
- Agent 可以自己查找发票、识别费用类型、匹配出差记录并填写报销单，这是它的决策边界；
- 但是否超过报销标准、用户是否有权限、超过 5000 元是否需要审批，必须由代码控制。
- 在此基础上，还要决定 Agent 是只能帮用户填写草稿，还是可以直接提交报销，这就是自主权取舍。
- 一旦允许 Agent 自主完成任务，就不能要求它每次都按照完全相同的步骤执行，而应该判断最终报销单是否正确、整个过程是否遵守公司制度，即 Outcome Correctness + Constraint Correctness。
- 如果 Agent 匹配错了发票，不能简单 Retry 再错一次，而应该根据情况重新匹配、重新规划，风险较高时转人工，这就是 Failure Control。
- 最后，即使所有接口调用都成功，也仍然需要知道 Agent 为什么选择这张发票、为什么归类为差旅费、是否触发过规则、最终结果是否正确，因此必须记录完整决策和执行过程，这就是Observability。
1. 决策边界：哪些事情可以交给 AI？
这是 Agent 架构首先要回答的问题。
传统 Workflow 的执行路径由代码决定，例如：
输入 → 问题改写 → 元数据召回 → SQL 生成 → SQL 校验 → 执行
Agent 出现以后，模型可以根据当前目标和执行结果动态决定下一步做什么。系统因此第一次把部分"控制权"交给了模型。
但模型具有概率性，所以不能把所有控制权都交出去。架构上需要明确区分两类决策：
- 不确定性决策交给 AI：意图理解、Planning、Tool Selection、信息检索、结果判断、Replan。
- 确定性规则交给代码：Permission、Quota、Transaction、Idempotency、Resource Limit、Audit、Safety Policy。
例如 NL2SQL 中，Agent 可以判断用户到底想查询什么、应该召回哪些元数据、SQL 是否需要重新生成；但用户有没有权限访问某张表、SQL 是否允许执行、最多扫描多少数据，必须由确定性代码控制。
因此第一条原则是：
AI 负责处理不确定性，代码负责守住确定性边界。
换句话说，Agent 可以决定怎么完成任务 ，但不能决定系统规则要不要遵守。
2. 架构取舍：应该给 Agent 多大的自主权？
划定决策边界之后，下一个问题自然出现：
边界应该画在哪里？
边界越大，Agent 自主性越强，可以解决更加开放的问题；但执行路径也越不可预测，测试、成本、安全和治理难度都会增加。
因此很多看起来不同的 Agent 架构问题，本质上都是自主权的 Trade-off：
- Workflow vs Agent：是否需要把执行路径的决定权交给模型？
- Single Agent vs Multi-Agent：决策权是否需要进一步拆分和协作？
- Autonomy vs Control：Agent 可以连续自主执行到什么程度？
- Context vs Cost：为了提高决策质量，值得给多少上下文？
- Quality vs Latency：为了提高结果质量，允许多少轮思考和 Tool 调用？
- Retry vs Cost：为了提高成功率，允许消耗多少额外资源？
- Memory vs Privacy：为了获得长期能力，哪些信息允许被长期保存？
这些问题背后其实只有一个核心判断：
增加的自主性带来的业务收益，是否大于它引入的工程复杂度和风险？
因此 Agent 架构并不是自主性越高越先进。更合理的原则是：
使用满足业务目标所需的最小自主性。
能通过 Workflow 稳定解决的问题，不需要 Agent 化；Single Agent 能解决的问题，也没有必要为了形式上的"职责拆分"直接变成 Multi-Agent。
3. 正确性：路径不确定以后，什么叫"做对了"？
自主权增加之后，会产生一个必然结果：
执行路径开始不确定。
同一个任务，第一次可能：
A → B → C → 完成
第二次可能：
B → A → D → C → 完成
如果两个过程都正确完成了业务目标，就不能再要求 Agent 必须按照固定路径执行。
因此 Agent 系统的正确性需要从传统的：
Path Correctness
逐渐转向：
Outcome Correctness + Constraint Correctness
具体来说：
-
Outcome Correctness：结果是否正确？
例如 SQL 是否正确回答问题、退款是否成功、工单是否正确创建。
-
Constraint Correctness：过程是否始终遵守约束？
例如有没有越权、有没有重复退款、有没有超过预算、有没有执行禁止操作、有没有绕过人工审批。
因此 Agent 可以拥有一定程度的过程自由 ，但不能拥有结果和规则的自由。
这进一步改变了测试体系。
传统测试更多验证：
Input → 固定 Path → Expected Output
Agent 则需要验证：
Goal → Outcome + Constraints
所以 Eval 在 Agent 系统中不应该只是模型评测，而应该逐渐成为与单元测试、集成测试、E2E 测试类似的工程质量基础设施：持续判断一个具有非确定性的系统，是否仍然能够稳定完成业务目标并遵守系统约束。
4. Failure Thinking：Agent 做错以后怎么办？
只要允许 Agent 自主决策，就必须接受：
Agent 一定存在判断错误。
因此正确性定义完成之后，下一个架构问题不是"怎么让 Agent 永远正确"，而是：
Agent 判断错误以后，系统如何控制影响？
传统分布式系统主要面对的是执行失败：
DB Down、Network Timeout、Service Crash、MQ 重复消息。
Agent 在此基础上增加了另一类失败：
Decision Failure。
例如：
选错 Tool → 参数错误 → Tool 正常执行 → 错误理解返回结果 → 错误 Replan → 错误进一步扩大
这里最危险的地方在于：整个链路可能没有任何 Exception。
HTTP 全部返回 200，数据库正常，服务正常，但业务已经错了。
因此 Agent Failure Recovery 不能简单等于 Retry × 3。必须区分失败类型：
- Retry：执行路径正确，只是发生临时技术故障。
- Replan：当前决策路径本身可能错误，需要重新规划。
- Fallback：当前模型或 Tool 无法可靠完成任务，切换方案。
- Human Handoff：风险超过自动化边界，转人工处理。
- Terminate：超过循环次数、成本预算或安全边界，直接终止。
所以 Agent 的 Failure Thinking 与传统系统相比发生了一个重要变化：
从**"组件失败以后如何恢复"，扩展为"决策错误以后如何限制 Failure Radius 并恢复"**。
目标不是保证 Agent 永远不犯错，而是做到：
错误可限制、可发现、可恢复。
5. 可观测性：如何知道 Agent 做错了？
Failure Thinking 最终又会推导出最后一个问题：
如果 Agent 的错误没有 Exception，我们怎么知道它错了？
这正是传统 Observability 在 Agent 系统中需要扩展的原因。
传统监控主要回答：
系统有没有正常运行？
所以关注 QPS、CPU、Memory、Latency、Error Rate、Log、Metric、Trace。
Agent 还必须回答：
系统虽然正常运行，但 Agent 有没有正确完成任务？
因此需要能够还原完整的决策链：
Goal → Context → Decision → Tool → Observation → Replan → Outcome
并在此基础上观察四个维度：
- Reliability：系统有没有正常执行？
- Quality：Agent 有没有正确完成任务？
- Safety：Agent 有没有突破决策边界？
- Efficiency：完成任务消耗了多少 Token、Model Call、Tool Call、时间和成本？
这样 Trace、Eval、Safety、Cost 就不再是四套独立能力：
- Trace：Agent 为什么这么做？
- Eval：最终做得对不对？
- Safety：过程中有没有越界？
- Cost：为了完成任务付出了多少代价？
它们共同构成 Agent 的反馈系统。
6. 最终形成一个完整的 Agent 架构闭环
把前面的五个问题连起来，Agent 架构的逻辑就比较清楚了：
1. Decision Boundary
先划定：
AI 能决定什么？
↓
2. Autonomy Trade-off
再决定：
给 AI 多大的自主权最合适？
↓
3. Correctness
自主决策导致路径不确定，因此重新定义：
什么叫"做对了"？
↓
4. Failure Control
既然模型一定可能判断错误，就继续解决：
做错以后如何限制影响并恢复？
↓
5. Observability
而决策错误又不一定产生 Exception，因此必须解决：
怎么发现它做错了，并把结果反馈回来？
最终形成：
Boundary → Decision → Execute → Evaluate → Recover → Feedback
这才是 Agent 架构真正的主干。
LLM、RAG、Memory、MCP、Tool、Multi-Agent、Guardrail、Sandbox、Checkpoint、Human-in-the-loop 都可以放到这条主干下面理解，它们是解决具体架构问题的技术手段，而不是架构本身。
因此，从架构师视角看，Agent 时代真正增加了一种新的管理对象：
智能决策的不确定性。
传统架构主要管理网络、节点、数据、并发带来的不确定性；Agent 架构在这些问题之上，又增加了对决策不确定性的治理。
最终可以把 Agent 架构设计压缩成三个判断标准：
- 决策可以不确定，但决策边界必须确定。
- 执行路径可以不确定，但结果和约束必须可验证。
- Agent 可以犯错，但错误必须可发现、可限制、可恢复。
这三个原则基本可以作为后续分析 Agent 架构问题的总纲。