Skip to main content

现在很多公司一开会,就会有人说:我们是不是也该做个 Agent?听起来很先进

  1. 现在很多公司一开会,就会有人说:我们是不是也该做个 Agent?

    听起来很先进。但问题是,很多所谓的 Agent 项目,从一开始就不该启动。

    最近也有些同学跑过来问我,上来就拿着一个场景问要怎么设计对应的 Agent。

    我觉得大家首先得想清楚,你的需求场景到底适不适合做 Agent,再考虑怎么做的问题。

    Anthropic 的工程师最近给了一个判断框架,我觉得非常中肯,分享给大家。

    在考虑要不要做个 Agent 时,就看下面四个问题:

    一、任务够不够模糊?

    如果一件事能写成明确的步骤,并且能产出确定性的结果,那用脚本或工作流就行了,不需要 Agent。

    Agent 解决的是 "你只能给目标,没法写死路径" 的问题。

    比如分析代码性能下降的原因,比如把一个模糊需求拆成技术方案 —

    中间要判断、搜索、比较、调整,没有固定路线。

    流程非常清楚的事,别上 Agent。

    路径不确定的事,才轮得到它。

    二、值不值得做?

    Agent 不免费。

    模型成本、工程投入、权限管理、异常处理、人工审核 — 全是钱。

    如果一个人每天花两分钟点几下按钮,你搞一个 Agent 来省这两分钟,投入产出比大概率是负的。

    值得做的场景长这样:重复发生、吃高价值人力、决策复杂、结果对业务有明显影响、做好后能规模化复用。

    Agent 不该解决 "有点烦" 的问题,该解决 "很贵" 的问题。

    三、瓶颈到底在哪?

    很多人看到任务没做好,第一反应就是"做个 Agent"。

    但得先分清:问题是流程需要编排,还是模型本身不行?

    比如全自动 Coding Agent,听着很美。

    但如果模型连基础代码修改都经常写错,那你做出来的不是自动开发,是自动制造 bug。

    虽说 Harness 做好后可以提升上限,但前提也得是模型的能力本身能过关。

    底层不稳,上层编排再漂亮也白搭。

    模型能力没验证清楚之前,别急着做 Agent。

    四、搞砸了代价多大?

    整理文档、生成草稿,错了可以改。

    但删数据库、发合同、改线上配置、封账号 — 这些事错一次可能就是事故。

    高风险场景不是不能用 Agent,但不能让它完全自主。

    哪些动作自动执行,哪些必须人确认,出错能不能回滚 — 这些边界必须提前画好。

    当老板说 "做个 Agent 吧" 的时候,先拿这四个问题过一遍:

    模糊度够高吗? - 价值够大吗? - 瓶颈是 Agent 能解决的吗? - 出错代价可控吗?

    答得清楚再动手。