AI Agent 不是聊天机器人：从 Prompt 走向 Runtime
很多人学习 AI，第一反应是研究模型、提示词和参数。但真正进入工程现场后，会发现一个 Agent 的质量，很少只由模型决定。
一个可用的 Agent，本质上是一个有状态的任务执行系统：它接收目标，读取上下文，选择工具，执行动作，验证结果，处理失败，并把状态交给下一轮继续。
一、从“模型调用”变成“控制循环”
最简单的 AI 应用只有一条链路：用户提问 → 模型回答。生产级 Agent 则至少包含六个环节：
- 模型：负责理解、规划和生成
- 状态：保存目标、进度、上下文、错误和审批结果
- 工具：连接搜索、数据库、代码、业务 API 和设备能力
- 控制器：决定何时调用模型、工具、重试或暂停
- 评测器：判断任务是否完成，而不只看文字是否流畅
- 观测系统：记录模型、工具、耗时、成本、失败和最终结果
因此，Agent 质量可以粗略理解为：
模型能力 × 上下文质量 × 工具可靠性 × 权限正确性 × 评测闭环
二、上下文不是越多越好
把所有历史消息、工具说明和知识库内容塞进上下文，看起来信息更全，实际可能让模型更差。上下文会出现噪声、冲突、过期和注意力稀释。
更可靠的做法是把信息拆成三层：
- 原始事件日志：保留完整过程，方便审计和重放
- 工作状态：只保留当前任务继续执行所需的信息
- 长期记忆：保存稳定事实、偏好和经验，并带来源、时间和失效策略
这也是为什么 Agent 需要 Context Engineering，而不只是 Prompt Engineering。
三、工具必须是受控能力
工具不是模型的“手脚”，而是系统暴露给模型的能力边界。每个工具都应该有明确输入输出、权限范围、超时、幂等性和副作用说明。
在机器人场景中，LLM 可以负责解释任务、生成高层计划和分析运维数据，但不应该直接控制底层运动。地图、路径、禁区、速度、电量和急停，必须由 typed command API、规则引擎、传统规划器和 watchdog 共同控制。
四、评测最终结果，也评测执行轨迹
一句回答看起来正确，并不代表 Agent 做对了。生产系统还要检查：
- 是否选对了工具
- 是否调用了不必要的工具
- 是否越过权限边界
- 是否在失败后正确恢复
- 是否把错误写进长期记忆
- 是否以合理成本完成任务
因此，评测对象应从“答案”升级为“任务轨迹”。
五、给 AI 架构师的结论
AI 系统的竞争力正在从“接入最强模型”转向“工程一个可测量、可恢复、可审计的运行时”。模型会不断变化，但状态管理、工具契约、权限策略、观测和评测，才是系统真正的长期资产。
对于企业 Agent，最值得先做的不是增加更多 Skill，而是建立四个基础能力：
- 有界上下文
- typed 工具契约
- 可恢复工作流
- 轨迹级评测
这四件事做好，换模型、接 MCP、加子 Agent 才不会变成堆功能。
