现在很多公司一开会，就会有人说：我们是不是也该做个 Agent？听起来很先进
现在很多公司一开会，就会有人说：我们是不是也该做个 Agent？
听起来很先进。但问题是，很多所谓的 Agent 项目，从一开始就不该启动。
最近也有些同学跑过来问我，上来就拿着一个场景问要怎么设计对应的 Agent。
我觉得大家首先得想清楚，你的需求场景到底适不适合做 Agent，再考虑怎么做的问题。
Anthropic 的工程师最近给了一个判断框架，我觉得非常中肯，分享给大家。
在考虑要不要做个 Agent 时，就看下面四个问题：
一、任务够不够模糊？
如果一件事能写成明确的步骤，并且能产出确定性的结果，那用脚本或工作流就行了，不需要 Agent。
Agent 解决的是 "你只能给目标，没法写死路径" 的问题。
比如分析代码性能下降的原因，比如把一个模糊需求拆成技术方案 —
中间要判断、搜索、比较、调整，没有固定路线。
流程非常清楚的事，别上 Agent。
路径不确定的事，才轮得到它。
二、值不值得做？
Agent 不免费。
模型成本、工程投入、权限管理、异常处理、人工审核 — 全是钱。
如果一个人每天花两分钟点几下按钮，你搞一个 Agent 来省这两分钟，投入产出比大概率是负的。
值得做的场景长这样：重复发生、吃高价值人力、决策复杂、结果对业务有明显影响、做好后能规模化复用。
Agent 不该解决 "有点烦" 的问题，该解决 "很贵" 的问题。
三、瓶颈到底在哪？
很多人看到任务没做好，第一反应就是"做个 Agent"。
但得先分清：问题是流程需要编排，还是模型本身不行？
比如全自动 Coding Agent，听着很美。
但如果模型连基础代码修改都经常写错，那你做出来的不是自动开发，是自动制造 bug。
虽说 Harness 做好后可以提升上限，但前提也得是模型的能力本身能过关。
底层不稳，上层编排再漂亮也白搭。
模型能力没验证清楚之前，别急着做 Agent。
四、搞砸了代价多大？
整理文档、生成草稿，错了可以改。
但删数据库、发合同、改线上配置、封账号 — 这些事错一次可能就是事故。
高风险场景不是不能用 Agent，但不能让它完全自主。
哪些动作自动执行，哪些必须人确认，出错能不能回滚 — 这些边界必须提前画好。
当老板说 "做个 Agent 吧" 的时候，先拿这四个问题过一遍：
模糊度够高吗？ - 价值够大吗？ - 瓶颈是 Agent 能解决的吗？ - 出错代价可控吗？
答得清楚再动手。
听起来很先进。但问题是，很多所谓的 Agent 项目，从一开始就不该启动。
最近也有些同学跑过来问我，上来就拿着一个场景问要怎么设计对应的 Agent。
我觉得大家首先得想清楚，你的需求场景到底适不适合做 Agent，再考虑怎么做的问题。
Anthropic 的工程师最近给了一个判断框架，我觉得非常中肯，分享给大家。
在考虑要不要做个 Agent 时，就看下面四个问题：
一、任务够不够模糊？
如果一件事能写成明确的步骤，并且能产出确定性的结果，那用脚本或工作流就行了，不需要 Agent。
Agent 解决的是 "你只能给目标，没法写死路径" 的问题。
比如分析代码性能下降的原因，比如把一个模糊需求拆成技术方案 —
中间要判断、搜索、比较、调整，没有固定路线。
流程非常清楚的事，别上 Agent。
路径不确定的事，才轮得到它。
二、值不值得做？
Agent 不免费。
模型成本、工程投入、权限管理、异常处理、人工审核 — 全是钱。
如果一个人每天花两分钟点几下按钮，你搞一个 Agent 来省这两分钟，投入产出比大概率是负的。
值得做的场景长这样：重复发生、吃高价值人力、决策复杂、结果对业务有明显影响、做好后能规模化复用。
Agent 不该解决 "有点烦" 的问题，该解决 "很贵" 的问题。
三、瓶颈到底在哪？
很多人看到任务没做好，第一反应就是"做个 Agent"。
但得先分清：问题是流程需要编排，还是模型本身不行？
比如全自动 Coding Agent，听着很美。
但如果模型连基础代码修改都经常写错，那你做出来的不是自动开发，是自动制造 bug。
虽说 Harness 做好后可以提升上限，但前提也得是模型的能力本身能过关。
底层不稳，上层编排再漂亮也白搭。
模型能力没验证清楚之前，别急着做 Agent。
四、搞砸了代价多大？
整理文档、生成草稿，错了可以改。
但删数据库、发合同、改线上配置、封账号 — 这些事错一次可能就是事故。
高风险场景不是不能用 Agent，但不能让它完全自主。
哪些动作自动执行，哪些必须人确认，出错能不能回滚 — 这些边界必须提前画好。
当老板说 "做个 Agent 吧" 的时候，先拿这四个问题过一遍：
模糊度够高吗？ - 价值够大吗？ - 瓶颈是 Agent 能解决的吗？ - 出错代价可控吗？
答得清楚再动手。