何时不该构建AI智能体（改做这些事）

目录

2026年8月发布。

TL;DR： 大多数AI智能体的想法，用的都是错误的工具。在写任何一行智能体代码之前，我会检查五个会让它出局的信号——流程不稳定、频率太低、没有能判断对错的测试、已经有更简单的工具能用，或者存在一个我来不及设好门控的不可逆失败模式。只要其中一条成立，我就不构建。我会转而沿着一架更便宜的替代方案梯子往下走，只有当梯子上没有一级真正管用时，才会回头考虑定制智能体。

【运营者视角】 我在一个咨询品牌和Pickleland（德克萨斯州普夫卢格维尔的匹克球场馆）之上运行着30多个生产环境智能体。我否决过的智能体想法，至少和我做出来的一样多，而且几乎没有一个是因为想法本身不好而死掉的——它们死掉，是因为对那项具体工作来说，智能体是错误的工具。这篇文章就是我在「要不要构建」变成「怎么构建」之前，会先跑一遍的筛选流程。

默认答案是不要做

我用的ROI框架能告诉你一项自动化能否收回它的构建和维护成本。这是正确的第二个问题。第一个问题更简单，却经常被跳过：这件事到底需不需要做成一个智能体？

「智能体」已经变成了任何涉及LLM的东西的默认标签，就像十五年前「App」变成了任何涉及屏幕的东西的默认标签一样。并不是每个接触到模型的东西都需要一个常驻的、自主的、能调用工具、监听触发条件并自行采取行动的系统。很多人所说的「构建一个智能体」，实际上是「写一段非常好的提示词，然后手动运行它」——这不是一种失败模式，反而常常是正确的最终形态。

我把「构建一个定制智能体」当作一架选项梯子上最贵的那一级，而不是第一级。在伸手去够它之前，我会先检查这项任务是否自己就已经被排除在外。

五个信号说明智能体是错误的工具

以下任何一条，单独就足以让我停下来。

1. 流程还不稳定。 如果这个工作流程在过去一个月里已经改过两次——因为业务本身还在摸索它到底想要什么——那么一个智能体锁定的只是一个即将再次改变的「今天版本」的流程。每次流程变化，你都要重写提示词、工具schema和评测集——也就是说，你在维护一个智能体，而不是在经营业务。先手动运行，直到它在一个季度里保持不变，再把这个已经稳定下来的版本自动化。

2. 运行频率太低，收不回成本。 一年只发生两次的任务，无论构建出来之后表现多好，都不会积累出足够多的执行次数来证明构建时间、测试时间和评测集的投入是值得的。低频率、高构建成本几乎是自动化里最糟糕的那个象限——你付出了全部的构建成本，却几乎收不到任何节省下来的收益。

3. 你写不出一个能判断对错的测试。 如果你没办法提前描述清楚一个正确的输出应该是什么样子、清楚到可以用程序去检查它，那你就没法为它构建一套评测框架——而一个你没法评测的智能体，就是一个你在盲飞的智能体。纯粹靠品味判断的任务（「这听起来像不像我」）、或者没有一致评判标准、纯靠主观判断的任务，只能保持手动，或者每次都需要人工复核——这就违背了自动化它们的初衷。

4. 已经有更简单的工具能完成这件事。 在为一个智能体划定范围之前，先问问一个电子表格公式、一个只有单个LLM步骤的Zapier/Make/n8n工作流，或者一个保存好的提示词，能带你走到哪一步。如果诚实的答案是「已经完成了90%」，那剩下的10%很少值得为此搭建一个拥有自己的基础设施、监控和维护成本的智能体。我见过有人为一个用筛选视图加一个循环日历提醒就能同样解决的任务，去规划一个智能体。

5. 失败模式不可逆，而你没有时间把门控搭建到位。 有些操作——批量发送邮件、退款、公开发帖——是无法撤销的。人工在环的审批门控正是为这种情况存在的，但一个仓促搭建、根本没人真正去审查的门控，比完全不做自动化还要糟糕：它制造出一种「有监督」的表象，却没有监督的实质。如果你没有时间把这个门控正确地搭建起来并配上人手，那是一个该放慢脚步的信号，而不是跳过门控的理由。

如果这五条都不成立——流程稳定、运行频率足够高、你能定义什么是正确的、没有更简单的工具能覆盖它、失败模式要么可逆要么被妥善地设了门控——那么就值得为它算一算ROI了。

构建之前，我会先爬这架梯子

当一项任务没通过五条检查中的某一条——甚至在我还没走到那一步之前——我就会按顺序往下爬这个清单，在第一个真正能解决问题的那一级停下来。

1. 直接问模型。 不需要包装层，不需要工具调用，不需要常驻基础设施。打开Claude，粘贴上下文，提出问题，用它给出的答案。这解决的一次性和偶发性任务比人们想象的要多，因为「做个智能体」的本能冲动，连只需要发生一次的事情也会触发。

2. 一段保存下来的提示词或项目说明。 如果同一类请求反复出现，但每一次仍然需要一个人来收集输入并审核输出，那就把这段提示词保存成一个模板——项目说明、自定义指令集、一个片段——而不是把触发条件自动化。你能得到智能体带来的一致性好处，却不用承担那套基础设施。

3. 一个只有单个LLM步骤的无代码自动化工具。 对于确实需要一个触发条件（一份新的表单提交、表格里的新一行）、但逻辑本身很简单的任务，一个在中间插了一次模型调用的工作流工具，构建和维护成本都比定制代码低得多。只要触发条件是标准的、量是低到中等的，我都会先用它，而不是上定制基础设施。

4. 一份手动运行的模板。 有些流程从清单里获得的价值，比从自动化里获得的更多，因为价值在于一个人认真过一遍每一步，而不在于速度。在那些「思考本身就是重点」的任务上，不要把思考自动化掉。

5. 外包。 对于任何真正存在模糊性或需要判断力、而你又没有时间去构建和维护一套评测集的事情，一个人——一名虚拟助理、一位专家，或一个产品化服务提供商——往往比一个你还在调校中的智能体更快上手，中途出错也更容易纠正。

6. 只有到这一步，才轮到定制智能体。 如果你已经把这架梯子爬到底，没有一级真正管用——触发条件需要在高负载下做出真正的判断、量大到手动或外包都处理不过来，并且它能通过ROI测算——这时候一个拥有自己可靠性体系的定制智能体，才配得上它的构建成本。

两周影子测试

对于那些卡在边界上的任务——通过了五项检查，但我心里还是没底——我会先跑一次为期两周的影子测试，再决定是否动手构建。我自己去做这项任务，把模型当作副驾驶而不是自主系统来用：用我最终会给智能体的同一份提示词、同样的输入，但每一个输出在被送到任何地方之前，我都会先读一遍。

这个测试能带来两样东西。第一，模型在我需要的质量标准下，到底擅不擅长这项任务——如果我要手动重写它一半的输出，那不管别的条件如何，这项任务都还没到可以自动化的时候。第二，一套真实的评测集：两周积累下来的输入，加上我判断为正确的输出，正是一套评测框架所需要的东西——等我决定动手构建的时候，这套东西我通常已经免费攒好了。

影子测试还能在边缘情况进入生产环境之前，先把它们暴露出来。在一次手动试运行里发现15%的输入需要特殊处理，要比智能体上线之后从客户投诉里发现它便宜得多。

否决一个想法之后，我会遵守的一条规则

否决一个智能体的想法，不等于否决背后那个真实的问题。如果一项任务目前自我否决了——流程还在变、量还太低——我会写下原因，并定一个大致的复查节点（通常挂钩一个具体的触发条件，比如「等预订量超过每周50单再复查」，而不只是一个日期）。只被否决一次、之后再也没被重新审视过的智能体想法，会悄悄变成永久性的手动工作，没人记得它其实被评估过两次。

反向的纪律同样重要：一个通过了五项检查和ROI测算的想法，也不会因此自动在今天就被构建出来。它会进入和其他所有想法一样的排期，和已经证明能收回成本的自动化项目一起被排优先级。通过这道筛选，只是为一项任务在队列里挣到一个位置，而不是让它豁免于优先级排序。

常见问题

这难道不是在反对自动化吗？

不是——这是在反对默认选择最昂贵的那种自动化形式。上面梯子上大多数的替代方案仍然是自动化，只是更轻量。我在运行几十个生产环境的智能体。这篇文章的重点不是避免构建，而是不要一上来就跳到「构建一个定制智能体」，如果一段保存好的提示词或一个无代码工作流，能用一小部分构建和维护成本带来同样的结果。

如果这项任务的量以后明显会增长呢？

这是一个提前于当前数字去构建的正当理由——我在ROI框架里讲到了这个例外情况。但它并不能推翻上面那五个信号。如果流程还不稳定，或者你还定义不出什么是正确输出，量的增长只意味着你将在更大的规模上维护一个坏掉的智能体。先解决稳定性和可评测性，规模是让你在这两点解决之后更早动手的理由，而不是跳过它们的理由。

我怎么判断一个无代码工具的步骤是「足够好」，还是需要定制代码？

先试一下，用你的评测集（哪怕是非正式的）去衡量它。无代码LLM步骤在处理单一目的、单一输入的任务时表现不错。一旦你需要多步工具调用、跨运行的持久状态，或者工具的构建器无法清晰表达的条件逻辑，它们就开始吃力。如果你撞上了这堵墙，那才是转向定制基础设施的真实信号——而不是一开始就从那里入手的理由。

这套标准对内部工具和面向客户的工具适用方式不同吗？

五个信号的适用方式是一样的，但风险不同。一个流程不稳定的内部工具出问题时，浪费的只是你自己团队的时间。一个流程不稳定的面向客户的工具，会侵蚀那些根本没签约成为你的评测对象的人对你的信任。我尤其会用一套更严格的版本去要求面向客户的自动化满足第五个信号——当出错时站在另一端的是一个陌生人而不是同事，「妥善设了门控」的门槛就要更高。

你否决智能体想法最常见的原因是什么？

信号三——没有一个干净的、能判断对错的测试。这是在划定范围阶段最容易被忽略的一条，因为任务感觉上定义得挺清楚，直到你真的试着提前写下来「一个正确的输出到底长什么样」。如果我没法用一两句话说清楚这一点，我就知道这个智能体会变得无法评测——也就意味着无法改进——也就意味着它现在还不该被构建出来。