AI agent 架构不能只有模型和工具循环。生产设计需要分离身份、工具、任务状态、长期记忆、持久执行、后端服务和遥测，因为每一层负责处理不同类型的故障。
最清晰的测试场景是在两次外部写入之间发生崩溃。系统应该知道谁执行了操作、哪些操作已经完成、哪些操作可能已经完成，以及从哪里恢复，而不是让模型根据对话文本重建事实。
从执行路径开始
flowchart TB
Trigger[User or event] --> Loop[Model and agent loop]
Loop --> Policy[Identity and policy]
Policy --> Tools[Tool registry]
Tools --> Durable[Durable execution]
Durable --> Backend[Backend services]
Loop <--> State[(Task state)]
Loop <--> Memory[(Long-term memory)]
Loop --> Telemetry[Traces, logs, metrics, evals]
Tools --> Telemetry
Durable --> Telemetry
Backend --> Telemetry
模型提出下一步操作。策略判断该身份是否可以执行。工具层将决策转换为范围明确的契约。持久执行围绕外部影响记录进度。后端服务保存权威业务数据。遥测让用户能够还原整次运行。
这条路径属于更广泛的生产环境 agent 技术栈，但针对一条真实工作流绘图，比画出公司里的每项服务更有用。
每一层只保存一种事实
模型循环负责选择，但不负责授权
循环包含提示词、近期消息、工具结果和停止规则。它可以选择工具，但下游系统必须强制执行权限。提示词中的“只读取发票”只是指导，不是访问控制边界。
工具公开范围明确的操作
工具契约会命名操作、限制参数，并返回下一步决策所需的字段。不能因为模型能够描述需求，就向它公开范围广泛的管理 API。MCP 工具设计指南介绍了工具选择、schema、稳定错误和安全写入。
身份与策略决定允许发生什么
将租户、用户、agent 和委托权限范围传递给实际执行操作的系统。高影响调用前应进行策略检查，并在审计记录中保留决策。服务端可以从凭据推导租户 ID 时，绝不能要求模型提供。
任务状态记录当前运行进度
任务状态包括当前步骤、已完成操作、待处理审批、重试次数和下一次计划执行时间。创建它的进程终止后，状态仍应保留。对话记录可以作为运行输入，但不能可靠记录事务状态，因此无法替代显式状态。
记忆在多次运行之间传递选定事实
记忆可以包含用户偏好、以往摘要或检索到的文档。它属于可能出错的上下文，因此需要保留来源、保留期限和删除规则。不要只用一句“发票已发送”的记忆来记录不可逆的外部影响，这项事实应写入权威后端状态。
持久执行能够抵御中断
持久执行负责协调重试、检查点、等待和恢复。Temporal 将其定义为通过重放已记录的事件历史，使执行在崩溃或服务中断后继续进行。即使你选择实现较小的操作账本而不是采用 Temporal，这个模型仍然适用。参见 Temporal 的持久执行说明和详细的 agent 持久性指南。
后端服务保存业务事实
订单、付款、文件、权限和客户记录存放在能够强制保证自身不变量的系统中。Agent 应通过范围受限的 API 或工具访问这些系统。模型响应可以解释一笔订单，但不能成为订单的权威记录。
遥测重新连接完整路径
使用一条追踪记录串联模型调用、工具选择、策略检查、工具执行和下游请求，其中应包含操作 ID 和脱敏后的参数。日志记录事件，指标体现整体运行状况，评估验证预期行为，三者不能相互替代。
选择产品前先区分故障类型
Agent 在超时后重复发送邮件，应检查持久执行和幂等性。它在下周记错用户偏好，应检查记忆和来源。它读取了其他租户的记录，应检查身份和授权。它选择 delete_project 而不是 archive_project，则应检查模型可见的工具集和工具选择测试。
购买一个“agent 平台”不会消除这些边界，只会改变负责它们的组件。请明确记录职责归属，包括产品名称背后的普通数据库或队列。
先画出最棘手的工作流
不要从只读聊天开始。选择一条会执行两次写入、等待审批、调用不可靠 API 或可能产生费用的工作流，在每项外部影响前后标记权威记录。下方的提示词会将这条路径转换为架构图，并指出哪些层目前只存在于模型上下文窗口中。