Agent 到底是什么：把模型从「会说」变成「会做」

「Agent」这个词被用得很泛，从自动回邮件的脚本到能自己写代码的系统都叫 Agent。剥掉营销包装，它的结构其实非常简单。

一个循环

观察 → 思考 → 调用工具 → 观察结果 → 再思考 → …直到完成

模型本身只会输出文本。Agent 的本质是把这个输出接到外部世界上：模型说「我要查一下天气」，运行时真的去调用天气 API，把结果塞回上下文，模型再决定下一步。这个循环转几圈，就表现为「自主完成任务」。

所以 Agent = 大模型 + 工具调用 + 循环控制。三者缺一，就退化成聊天机器人或普通脚本。

三个关键零件

1. 工具（Tools）

每个工具是一段有名字、有参数 schema 的函数。模型通过输出结构化的调用请求来使用它。工具设计得好不好，直接决定 Agent 的上限：

• 名字和描述要写清「什么时候该用」；
• 参数要收敛，别让它自由拼 SQL；
• 失败要返回可读的错误，模型才能自我修正。

2. 上下文管理

这是最容易被低估的部分。Agent 跑十几步之后，上下文里塞满了工具输出，真正重要的信息可能被淹没。主流做法是：只保留结论、把大块结果存到外部再按需取回、定期压缩摘要。

3. 停止条件

必须有硬性约束：最大步数、超时、预算上限、危险操作需人工确认。没有停止条件的 Agent 在真实环境里等于一个会烧钱的不确定循环。

它现在真正擅长什么

• 有明确成功判据的任务：跑测试直到通过、按 schema 抽取字段、把文档转成结构化数据；
• 需要多次试错的探索：搜索、读文件、改代码、再验证；
• 把多个已有工具串起来：这本来就是人写脚本干的事，模型只是省了写脚本。

它现在不太行的

• 长链条上的稳定推理：第 8 步的一个误判会让后面全部跑偏，且它往往不自知；
• 需要真实世界判断的模糊任务：什么算「处理好」，它自己定不了标准；
• 成本和延迟敏感的场景：多轮工具调用意味着多次前向，比单次问答贵一到两个数量级。

一个务实的判断

评估一个 Agent 系统，别看 demo，看失败时会发生什么：会不会卡死、会不会越权、会不会把错误结果当成功交付。能优雅失败的系统，才是能上生产的系统。