AI 交流论坛

判断一个 Agent 好不好用，不能只看 demo。Demo 里跑通一次不难，难的是连续跑 100 次还能稳定。 我会看这几个指标： 成功率：同类任务跑多次，多少次能完成 返工率：完成后还需要人改多少 可解释性：失败时能不能知道卡在哪一步 成本：一次任务平均花多少 token 和时间 权限边界：会不会调用不该调用的工具 恢复能力：中间失败后能不能重试或降级 很多 Agent 看起来聪明，其实只是“偶尔很惊艳”。但产品里需要的是稳定，不是抽奖。 我比较喜欢给 Agent 做一组固定评测集，比如 20 个真实任务，每次改 Prompt、换模型、换工具后都跑一遍。不要凭感觉判断“好像变聪明了”，要看数据。 还有一点很重要：评测不要只看最终答案。中间步骤也要看。一个答案对了但过程乱来的 Agent，迟早会在更复杂的任务里出问题。

现在很多需求一上来就想做 Agent，但我会先问一个很土的问题：这个任务的步骤能不能写死？ 如果能写死，先别上 Agent。用普通 Prompt、工作流、规则链，通常更便宜、更稳定、更好调。 适合 Prompt 的任务： 总结一篇文章 改写一段文案 从固定文本里抽字段 做简单分类 适合 Agent 的任务： 需要查资料 要调用工具 每一步取决于上一步结果 失败后要换策略 要操作外部系统 Agent 的问题不是“不强”，而是复杂度高。它会带来调试成本、token 成本、权限风险、失败重试，还有一个很现实的问题：出了错你不一定知道它是哪一步错的。 所以我的判断是：先工作流，后 Agent。先把能确定的步骤确定下来，只把真正需要模型判断的部分交给模型。 你们现在做的 Agent 项目里，有多少其实可以拆成普通工作流？

我用下来，Prompt 真正有用的不是“神奇咒语”，而是把人脑子里的默认条件写清楚。 一个稳定的 Prompt 通常要交代这几件事： 你是谁：让模型站在什么角色上回答 要做什么：任务边界越具体越好 给了什么材料：别让它自己脑补背景 有哪些限制：长度、语气、禁止事项、判断标准 输出成什么样：表格、JSON、步骤、短文都要说 有没有样例：一个好样例经常比十句形容词管用 比如不要只写“帮我优化这段文案”。可以写：“你是一个面向 B 端 SaaS 的产品营销编辑，请把下面文案改得更清楚，少用形容词，保留技术准确性，输出 3 个版本，每个不超过 80 字。” 这不是复杂，而是减少来回沟通。 我自己的习惯是：越重要的任务，越先让模型复述它理解的目标。它复述得不对，就不要急着让它生成。先对齐，再输出，效率反而更高。

我越来越觉得，AI 编程真正的成本不是模型费，而是上下文管理。 很多时候 AI 写不好，不是因为模型不行，而是它拿到的信息太乱：旧 README、过期注释、没说清楚的目录职责、没人维护的测试命令。它只能在一堆不确定信息里猜。 我现在会给项目准备几类“喂给 AI 的材料”： 项目入口：这个项目是干嘛的，核心模块在哪里 运行方式：开发、测试、构建分别怎么跑 代码规矩：命名、错误处理、日志、接口返回格式 禁区：哪些文件不要动，哪些逻辑要兼容旧数据 验证方式：改完至少跑哪些测试或命令 这些东西不只是给 AI 看，也是在帮团队自己整理知识。很多老项目没人敢改，本质上也是因为这些上下文散了。 还有一点：不要每次都把问题丢给 AI 从零理解。能沉淀到 README、CLAUDE.md、CONTRIBUTING 的，就沉淀下来。下一次它会更快进入状态，人也会更省心。 如果你觉得 AI 经常“理解错项目”，先别急着换模型，先看看你给它的上下文是不是本来就不够清楚。