AI 智能体

智能体不是“会聊天的模型”的另一个名字。它指的是一个能围绕目标持续工作的系统：读取环境信息，形成计划，调用工具，观察结果，再决定下一步。

如果大语言模型像一个会分析问题的人，智能体就是给这个人配上工作台、工具箱、任务单和检查结果。它的能力不只来自模型本身，也来自工具、状态管理、权限和反馈闭环。

与其他模块的关系

• 大语言模型提供推理和语言生成能力，见 大语言模型。
• MCP 提供标准化工具连接，见 MCP。
• Skill 提供可复用流程和约束，见 Agent Skill。
• AI 编程中的 Agent 工程化见 Vibe Coding。

智能体的基本循环

一个智能体通常包含五个动作：

1. 观察：读取用户目标、文件、网页、日志、数据库结果或工具返回。
2. 计划：把目标拆成步骤，判断风险和依赖。
3. 行动：调用工具，例如搜索、写文件、发请求、运行测试。
4. 反馈：读取执行结果、错误信息和验证结论。
5. 调整：根据反馈修正计划，直到完成或请求人工介入。

没有行动能力的只是聊天助手；没有反馈读取能力的只是脚本生成器；没有权限边界的智能体则很难安全落地。

智能体适合做什么

适合：

• 多步骤任务：需要先查资料、再处理、再验证。
• 环境相关任务：结果依赖文件、网页、数据库、日志或运行状态。
• 可验证任务：能通过测试、构建、截图、查询结果确认是否完成。
• 流程明确任务：步骤、权限、失败处理都能写清楚。

不适合：

• 目标模糊且没有验收标准。
• 高风险动作无法回滚，例如直接改生产数据。
• 需要大量价值判断但没有明确规则。
• 工具返回结果无法验证真伪。

智能体越能被工具验证，越适合自动化；越依赖主观判断，越需要人工在关键节点确认。

智能体系统的组成

组成	作用	风险点
模型	理解目标、生成计划、解释结果	幻觉、误解、过度自信
工具	读取和改变外部世界	权限过大、参数错误
记忆 / 状态	保存任务进度和关键事实	过期信息污染决策
约束	限制可做和不可做的事	规则不清导致越界
评估	判断任务是否完成	只看表面输出，缺少验证
人工确认	处理高风险决策	确认点过多会降低效率

这也是设计智能体时的检查清单。模型只是其中一层，不能替代权限、验证和流程设计。

场景示例

代码修改智能体

目标是修复 bug 或实现功能。它需要读取代码、定位调用链、修改文件、运行测试、解释 diff。

关键边界：

• 修改前先理解现有结构。
• 每次改动范围要可审查。
• 完成后必须运行验证命令。
• 对数据库迁移、鉴权、支付等高风险区域需要人工确认。

数据分析智能体

目标是从数据中找结论。它需要查询数据、清洗字段、生成统计、解释异常。

关键边界：

• 查询权限要最小化。
• SQL 和过滤条件要可审计。
• 结论要能回到数据来源。
• 不确定时应给出样本和限制，而不是强行下结论。

客服处理智能体

目标是分类工单、查询订单、生成回复或触发流程。

关键边界：

• 涉及退款、封禁、赔付等动作应有人审或规则确认。
• 回复必须基于知识库和订单状态。
• 低置信度问题转人工。
• 敏感信息要脱敏。

设计智能体的判断标准

问题	说明
目标是否可验收	没有验收标准，智能体只能“看起来完成”
工具是否必要	只回答问题不一定需要智能体
工具权限是否最小	只读能完成就不要给写权限
失败能否恢复	超时、异常、误操作是否能重试或回滚
是否需要人工确认	高风险动作要设计确认点
日志是否可追踪	需要知道它看了什么、做了什么、为什么做

常见误区

误区	问题	更合适的做法
把复杂提示词叫智能体	没有工具和反馈，无法完成真实任务	先补观察和验证能力
工具越多越好	选择成本高，误调用风险大	按场景提供少量清晰工具
完全自动化高风险流程	一次误判可能造成真实损失	关键动作加入人工确认
只看成功案例	演示样本容易避开边界	建立失败样例和回归测试
让智能体记住长期事实	记忆可能过期或污染	把事实放进可检索、可更新的数据源

总结

智能体的核心是闭环：观察、计划、行动、反馈、调整。可靠智能体不是让模型“自主发挥”，而是把目标、工具、权限、状态、验证和人工确认设计清楚。能验证、能回滚、能追踪，才适合把任务交给智能体持续执行。