从 Demo 到生产：可靠 AI Agent 系统的工程架构

一、可靠性首先来自模型之外

模型只是 Agent 系统中的一个组件。身份认证、策略、状态、数据访问、工具执行、重试、用户确认和结果校验，应由模型之外的应用层负责。如果这些职责全部隐藏在一段长提示词中，系统将难以测试，更难审计。

我更倾向于让模型输出结构化行动建议，由确定性代码判断它是否有效、是否具备权限、是否可以执行。建议可以包含工具名称、类型化参数、解释和置信信号；运行时再执行 Schema 校验、鉴权、预算控制、幂等规则及人工确认。

核心结论

强大的模型能够改善计划，但不应该成为保护系统的唯一机制。

二、工具定义就是产品契约

Agent 工具通常从一组带简短描述的函数开始，这对实验足够，但生产系统需要模型、运行时和工程团队都能理解的契约。契约应说明工具做什么、何时使用、哪些字段必填、哪些数据会离开系统，以及调用方必须处理哪些失败。

工具名称应表达业务意图而不是底层实现，例如 search_customer_orders 比 execute_query 更安全。输入尽可能使用受限枚举、明确单位；输出返回稳定标识和结构化证据，而不只是自然语言。错误需要分类，以便编排器区分临时网络故障、参数错误和权限拒绝。

三、编排系统必须暴露不确定性

单循环 Agent 写起来很简洁，却会隐藏关键运行状态。生产工作流更适合使用理解、检索、计划、请求授权、执行、校验和总结等命名阶段。将这些阶段表达成状态机或图，可以让流程可检查，并对每个状态转换独立测试。

只有当不同角色确实拥有不同上下文、工具、评估标准或安全边界时，多智能体才有价值。我会在分工能降低风险或提高可观测性时引入协调者，例如将数据采集、风险分析和最终报告分离。每增加一个 Agent，就增加一个必须治理的新接口。

核心结论

应选择能够清晰表达状态、职责和故障恢复的最小编排模型。

四、记忆是一套生命周期，而不是一个向量数据库

Agent 记忆经常被简化成把对话片段放入向量数据库，但不同信息具有不同寿命与可信等级。工作记忆服务当前任务；长期个人事实需要用户控制和来源；检索文档只是证据，不能自动成为事实；执行历史则服务调试与审计。

这些类别应拥有不同的保留、更新与删除规则。长期事实需要稳定标识与冲突解决机制；检索结果需要来源和新鲜度；摘要必须能追溯到被压缩的信息；敏感内容默认不应复制到追踪日志或长期存储。

五、观测最终结果，而不只是模型调用

Token 数和模型延迟有价值，却不能说明 Agent 是否真正解决了问题。我会追踪完整工作流：请求分类、检索质量、规划、工具选择、参数校验、外部延迟、重试、授权、结果验证、成本与最终结果。这条证据链能够同时支持工程和产品决策。

评估应结合确定性测试、场景集、策略检查和抽样人工复核。最有价值的案例往往不是通用榜单，而是贴近生产的模糊请求、过期数据、冲突来源、部分工具故障、权限被拒绝，以及用户中途改变方向。可靠系统应清晰降级，而不是在后台静默进行没有依据的即兴猜测。