过去一年，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 的未来当然值得期待。但越是强大的技术，越需要清醒地使用。
你认为呢？
