5月份写的文章忘记发了。。。过去一年AI Agent 几乎成了所有产品方案里的高频词。客服要 Agent销售要 Agent数据分析要 Agent内部运营也要 Agent。好像只要在原来的系统上加一个能自主规划、能调用工具、能多步执行的智能体产品就立刻进入了下一个时代。但 Anthropic 工程师 Barry Zhang 给出的建议很克制不要什么都做成 Agent。在 AI Engineer 的一次分享里他提出了一个非常实用的判断框架在决定要不要构建 Agent 之前先问四个问题。第一问这个任务到底有多模糊如果一个任务的步骤是固定的、路径是清楚的、分支是可以提前穷举的那它更适合用脚本、工作流或者传统自动化来解决。比如收到表单后发邮件、按固定规则生成报表、把用户问题分流到几个队列。这些事情并不需要一个自主思考的 Agent。你真正需要的是稳定、便宜、可控的流程。Agent 擅长的是模糊问题目标清楚但路径不确定步骤数量不可预知执行过程中需要根据环境反馈不断调整。比如从一个需求文档改出一组代码、调试一个未知 bug、研究一个开放问题并输出判断。这类任务没法提前写死每一步才是 Agent 发挥价值的地方。换句话说如果你能画出完整流程图就先别做 Agent。第二问这个任务的价值是否足够高Agent 的自主探索不是免费的。它会多轮思考、多次调用工具、反复检查和修正。相比单次模型调用或固定工作流Agent 往往意味着更高的 token 成本、更长的响应时间以及更多工程复杂度。所以 Barry Zhang 的判断很直接任务价值必须足以覆盖这些成本。如果一个高频客服问题每次只能承受几分钱成本却让 Agent 在里面来回探索经济账可能根本算不过来。更合理的做法是把常见场景做成稳定工作流只把少数复杂问题交给 Agent。但如果任务本身价值很高比如修复一个生产级 bug、完成一次高质量研究、自动化一项昂贵的专业工作那么成本就不是第一矛盾。此时只要 Agent 能把事情完成哪怕多花一点时间和算力也是值得的。判断 Agent不要只问能不能做还要问值不值得做。第三问关键能力是否已经过关很多 Agent 失败并不是因为架构不够华丽而是因为模型在关键节点上能力不足。一个代码 Agent关键能力可能是读懂代码库、写出正确补丁、运行测试、定位错误、从失败中恢复。只要其中一个能力明显短板整个 Agent 就会在那一环反复摔倒。这时继续堆多 Agent、复杂规划器、花哨框架往往只会放大问题。因为 Agent 的每一步都会依赖前一步的质量关键能力不过关错误会沿着执行链条复利增长。更稳妥的做法是缩小范围先让它处理更窄的任务给它更清楚的工具更明确的上下文更容易验证的环境。Agent 不是魔法放大器。它会放大能力也会放大短板。第四问出错的代价有多高Agent 越自主越要认真考虑错误代价。如果错误很容易发现、容易回滚、损失有限那么可以给 Agent 更多行动空间。代码场景之所以适合 Agent一个重要原因是结果可以用测试、CI、代码审查来验证。但如果错误难以发现或者一旦发生就会造成严重损失比如金融交易、医疗建议、法律决策、生产系统变更就不能轻易让 Agent 全自动执行。这类场景更适合加上人工审核、权限限制、只读模式、沙箱环境和分阶段确认。好的 Agent 系统不是追求完全不用人而是知道什么时候必须把人放回回路里。所以Agent 不是万能升级而是一种昂贵的自由度Barry Zhang 的核心观点可以总结成一句话Agent 最适合复杂、高价值、模型能力足够、错误可控的任务。这也是 Anthropic 在《Building effective agents》里反复强调的原则从最简单的方案开始只有当简单方案不够用时才增加复杂度。很多时候一个单次模型调用就够了再复杂一点可以用工作流只有当任务路径无法预先写死才需要 Agent。这和今天很多产品的做法正好相反。很多团队一上来就想做全能 Agent结果系统越来越复杂效果却不稳定。新的方向不要重复造 Agent而是沉淀 Skills在另一场演讲《Don’t Build Agents, Build Skills Instead》中Barry Zhang 和 Mahesh Murag 又进一步提出未来不一定是为每个领域重新造一个 Agent而是让一个通用 Agent 搭配大量可复用的 Skills。Skills 可以理解为一组打包好的专业能力说明文档、操作步骤、脚本、模板、示例、领域规则。它们像文件夹一样存在在需要时被 Agent 动态加载。这解决的是 Agent 的另一个核心问题模型很聪明但不一定有你的业务经验。一个通用 Agent 可能会写代码、调用工具、分析文件但它不知道你公司的报表格式、品牌规范、法务流程、财务口径、交付标准。Skills 的价值就是把这些可复用的专业知识沉淀下来让 Agent 每次都按同一套方法做事。从这个角度看企业真正要建设的也许不是一堆互相孤立的 Agent而是一套可复用的能力库。Agent 负责通用推理和执行Skills 负责领域知识和稳定流程。给团队的落地建议如果你正在规划 AI Agent不妨先用这四个问题做一次筛选任务是否足够模糊任务价值是否足够高关键模型能力是否已经可用出错代价是否可控如果答案并不理想先别急着做 Agent。也许一个脚本、一个工作流、一个更好的提示词、一个可复用 Skill就能解决大部分问题。Agent 的未来当然值得期待。但越是强大的技术越需要清醒地使用。你认为呢