从零理解 AI Agent：一套可落地的系统架构

Agent 不等于“会调用 API 的聊天机器人”

普通聊天应用通常只有一轮输入和一轮输出：用户给出问题，模型生成回答。AI Agent 则多了一个关键能力——它可以围绕目标持续观察环境、选择动作、执行工具、读取结果，再决定下一步。真正让系统成为 Agent 的不是某个模型名称，而是一个受约束的决策循环。

可以把 Agent 看成一个带概率决策器的软件系统。模型擅长理解非结构化目标和在不确定信息中做选择；传统代码负责权限、状态、校验、超时和持久化。两者的边界越清晰，系统越容易调试。

一个最小 Agent 至少包含五部分：

目标：本次运行要交付什么，什么条件算完成；
状态：已经知道什么、做过什么、还缺什么；
模型：根据当前状态提出下一步动作；
工具：搜索、读取、写入或调用外部系统；
控制器：限制循环次数、验证动作并决定停止或恢复。

一次任务的完整运行链路

假设用户要求“分析最近一周的客服工单并给出前三个产品问题”。系统不应把所有责任交给模型，而应按照明确的状态机运行：

while (!state.finished && state.step < limits.maxSteps) {
  const context = buildContext(state);
  const decision = await model.decide(context, toolSchemas);
  const action = validateDecision(decision, policy);
  const observation = await executeWithTimeout(action);
  state = reduce(state, action, observation);
  await checkpoint(state);
}

这个循环很短，却揭示了 Agent 的工程本质。模型只负责 decide，并不直接拥有数据库连接或文件系统权限。validateDecision 检查参数、权限和风险；executeWithTimeout 处理失败与超时；reduce 把工具结果转成下一轮可用的状态；checkpoint 让任务在进程崩溃后仍可恢复。

状态最好是显式结构，而不是不断变长的聊天记录：

{
  "goal": "找出本周前三个产品问题",
  "facts": ["已读取 1264 条工单"],
  "artifacts": [{"type": "query_result", "ref": "result-17"}],
  "openQuestions": ["是否排除退款咨询"],
  "step": 4,
  "budget": {"tokensLeft": 18000, "toolCallsLeft": 12},
  "status": "running"
}

显式状态有三个好处：可以测试，可以展示给运营人员，也可以在模型之外强制执行预算和业务规则。

分层比“超级 Prompt”更可靠

生产系统通常适合拆成四层。

交互层负责接收目标、补充信息和呈现进度。它不应该伪装成任务已经成功，而要区分“模型认为完成”和“系统验证完成”。

编排层拥有运行状态、步骤上限、重试、检查点和人工审批。这里应该使用确定性代码，而不是让模型自由决定所有控制流。

智能层包含规划、路由、总结和判断等模型调用。不同节点可以使用不同能力和成本的模型，没必要让最贵的模型处理格式转换。

执行层封装工具、凭据、沙箱和外部服务。工具返回的内容一律视为不可信输入；写操作必须拥有比读操作更严格的授权。

这套分层还有一个现实优势：当效果不佳时，团队可以判断问题究竟来自上下文、模型决策、工具返回，还是控制器的恢复策略，而不是只会修改 Prompt。

“完成”必须可验证

Agent 最危险的错觉是把一段流畅文字当成交付。成功标准应该尽量转成机器可以检查的条件。例如：

报告必须引用至少三个真实工单分组；
每个结论必须带查询结果引用；
写入动作返回业务主键后才算成功；
生成文件必须通过格式解析和大小检查；
涉及付款、删除或发送外部消息时必须等待人工批准。

可以让模型提出“我完成了”，但最终完成权应掌握在验证器手里。验证失败时，将具体错误写回状态，让 Agent 修正，而不是从头重跑。

从单循环开始，而不是先做多 Agent

很多项目一开始就设计主管 Agent、研究 Agent、写作 Agent 和审核 Agent，结果通信成本比任务本身还高。更稳妥的演进顺序是：

先实现一个有步骤上限的单 Agent 循环；
把高频路径固化为确定性工作流；
为不稳定步骤增加结构化验证和重试；
只有当任务确实可以并行、角色上下文明显不同，才拆成多个 Agent。

判断架构是否健康，可以问五个问题：任务能否中断恢复？每次工具调用能否追踪？模型能否越过权限层？成功是否由代码验证？成本能否在运行前和运行中限制？如果答案都是肯定的，这套 Agent 才具备进入真实业务的基础。

小结

AI Agent 的核心不是无限自主，而是在明确目标、有限权限和可观测状态中做动态决策。把模型放在它擅长的位置，把可靠性留给传统软件工程，往往比追求一个无所不能的自治体更接近可交付的产品。