识破Agent Washing：如何筛查伪Agent项目

当“Agentic AI”成为融资和发布会的万能前缀，一个更隐蔽的问题浮出水面：你看到的到底是一个能自主决策、执行动作的智能体，还是一个换了包装的聊天机器人？Chain of Thought 播客两位嘉宾的隔空争论，恰好提供了一套判断坐标。

同一市场，两种叙事

Spot AI 的 Kelly Vaughn 在第 15 期节目中直言 agentic AI 是泡沫，质疑“agentic AI for X”式的跟风叙事，包括大量同质化的 AI 会议记录工具。她认为噪音、薄弱的差异化以及对“首发”的执念，正在批量制造失败公司。

六周后，Lyzr 的 Siva Surendira 在第 21 期给出相反判断：agent 的采用速度远超预期，已经像云和数据库一样走入主流。他坦言自己也没料到这一轮会爆发得如此猛烈。

这两种说法并不互斥。一个工具品类可以被广泛采用，同时一大批挂着“agent”名号的项目根本不具备实质的智能体能力。广泛采用与过度炒作的提案，可以同时成立。

Agentic AI（智能体式 AI） 与普通生成式 AI 的关键区别在于「自主性」与「行动能力」。生成式 AI 通常是被动响应式：用户输入提示，模型返回文本或图像。而 agentic AI 被期望能够拆解目标、规划多步任务、调用外部工具或 API、根据中间结果调整策略，并在较少人工干预下完成端到端流程。业界通常用几个维度来区分：是否具备目标分解与规划、是否能自主调用工具执行动作、是否维护跨步骤的记忆状态、是否在遇到异常时自行重试或改道。正是这些能力门槛，使得 Gartner 认为数千家宣称 agentic 的厂商中只有约 130 家真正达标——多数产品只是把一次模型调用包装成了「agent」。理解这条分界线，是判断 agent washing 的前提。

用外部数据做交叉验证

仅凭两期播客的观点不足以支撑判断，需要引入第三方数据交叉验证。

据 Gartner 2025 年 6 月的预测，超过 40% 的 agentic AI 项目将在 2027 年底前被取消，原因集中在成本攀升、业务价值不清、风险控制不足。Gartner 估计，在数千家营销 agentic AI 的厂商中，只有约 130 家具备真正的智能体能力。它明确点出了失败模式：把现有助手、RPA 脚本和聊天机器人重新贴牌，却不具备实质的 agentic 能力——这就是“agent washing”。

另一组数据则支撑 Surendira 的采用论。微软与 LinkedIn 的 2024 工作趋势指数显示，75% 的知识工作者已在工作中使用生成式 AI。高频使用与大批项目夭折并存，这并不矛盾。

正确读法是把这些数字当过滤器，而不是当融资路演里的预测。40% 以上的取消率意味着，任何提案都需要证明自己为何属于幸存的那一半，而“大家都在用 AI”不是理由。

Agent washing 是类比「greenwashing（漂绿）」造出的术语，指厂商把已有的助手、聊天机器人或 RPA（机器人流程自动化）脚本重新贴上「agent」标签，却不增加任何实质的自主决策或行动能力。它的典型特征包括：交互仍是一问一答、动作仍按预设脚本执行、没有目标规划层、错误处理依赖人工。Gartner 在 2025 年 6 月的预测中把这一现象列为 agentic AI 项目大面积取消的原因之一，因为贴牌产品无法在真实业务中兑现「自主完成工作」的承诺，试点很快暴露出价值缺口。识别 agent washing 的实用方法，是要求厂商演示一个旧流程做不到的决策或动作，而不是展示一段更流畅的对话。

四问筛查一个提案

拿到一个 agent 项目提案，先用四个问题过一遍。答案必须用大白话写出来——如果需要靠“agent”这个词才能让答案显得成立，那答案本身就不成立。

第一，剥掉标签。 这是不是一个换了名字的助手、聊天机器人或 RPA 脚本，没有实质的智能体能力？如果是，Gartner 的术语就适用，要么放弃，要么诚实地改个名字。

第二，指出智能体部分。 它做了什么旧流程没有的决策、执行了什么旧流程没有的动作？Gartner 判定“真正的智能体能力”时用的就是这条线。一个调用模型、把文本发出去的包装层，达不到这个标准。

第三，对上三类取消原因。 用一句话说清业务价值；设定你愿意承受的成本上限；说明什么风险控制能拦住错误动作。成本攀升、价值不清、风控不足，正是 Gartner 预期大量项目被砍的三大原因。

第四，把任务匹配到人已经在做的重复性工作。 Vaughn 认为 AI 是好的增强工具，用对了能提效，但不会替代团队，也不会让团队规模翻倍。Surendira 则认为机会就在那些平凡、重复的工作里。如果提案宣称团队产能翻倍，直接判定筛查失败。

Surendira 还提到一个现实约束：企业今天做的 AI 工作中有 95% 停留在概念验证阶段，无法进入生产。原因包括担心法律诉讼，以及诸如本应批准 1 万美元退款却批了 10 万美元这类错误，还有幻觉、有害内容和提示注入。两个瓶颈同样明确：一是缺乏文档的定制应用，仍需有人定义 agent 可执行的动作；二是分散且未就绪的“部落数据”。

Vaughn 版本的门槛则是客户问题本身。她主张先问在解决什么问题、AI 是否真的帮得上忙。很多公司的问题根本不需要 AI。她把过度承诺视为最大陷阱，并强调永远不会有 100% 的准确率。在安全类动作上，一次漏检（她的例子是没检测到入侵）就足以失去信任。

RPA（Robotic Process Automation） 是基于规则的流程自动化技术，通过录制或编排固定的点击、填表、复制粘贴等操作来替代重复性人工劳动。它与 agentic AI 的核心差异在于「确定性」：RPA 严格按预设路径执行，遇到界面变化或异常输入就会失败，需要人工维护规则；agentic AI 则被期望在不确定环境中自主判断下一步动作。这也解释了为什么把 RPA 脚本改叫「agent」属于典型的 agent washing——它没有新增任何决策能力。反过来说，RPA 在规则稳定的高频任务上依然可靠且成本可控，筛查时不应一刀切否定，而应诚实区分：这是自动化，还是智能体。

一个筛查草图

原文给出了一个 Python 草图，仅用于示意筛查逻辑，不是生产级策略：

# 草图，示意筛查逻辑，非生产策略
def screen(p: dict) -> str:
    washed = p["rebranded_assistant_rpa_or_chatbot"]
    agentic = p["chooses_and_takes_a_real_action"]
    value = bool(p["business_value"].strip())
    cost_ok = p["cost_bound"] is not None
    risk_ok = bool(p["risk_control"].strip())
    repeated = p["replaces_a_repeated_human_task"]
    data_ok = p["needs_little_internal_data"] or p["data_and_actions_defined"]
    if washed or not agentic:
        return "drop"  # 按 Gartner 2025 年 6 月的定义，属于 agent washing
    if not (value and cost_ok and risk_ok and repeated and data_ok):
        return "narrow"  # 成本、价值或风控，正是取消原因
    return "worth a bounded experiment"

即便通过筛查，也不该跳过用户对话。Vaughn 主张在动手之前先和潜在客户聊，包括数据存在哪里、谁能访问。

通过筛查之后怎么办

把项目做得比提案更窄。Vaughn 拿会议记录工具开过玩笑：一场会有十几个人、好几个不同的 AI 记录工具，然后有人要再做“所有 AI 记录工具的 AI 记录工具”。如果你的差异化只是一个拥挤赛道里的又一个 agent，那你其实没有差异化。

如果项目涉及金钱、安全或记录系统，风控必须在演示之前就进入设计，而不是等试点出了问题再补。Surendira 提到，管理式编排与 DAG 编排结合仍无法解决关键用例，真正提升确定性的是引入代码、SQL、机器学习和深度学习 agent。你未必需要他那套技术栈，但规则可以借用：如果你说不出被允许的动作是什么、拦住错误动作的检查是什么，这个项目还停留在提案阶段。

最后是一条实用清单：

• 用不带 agent 标签的语言写清任务。如果它仍是助手、聊天机器人或 RPA，就称之为 agent washing 并停下。
• 要求一句话的业务价值、一个成本上限、一个具名的风险控制。
• 优先选择人已经在做的重复任务，并给出可校准的增强承诺，拒绝团队翻倍或淘汰的说法。
• 如果依赖老旧内部应用或分散数据，先定义动作和数据，否则换一个几乎不需要内部数据的任务。
• 把“通过”视为一次有边界的实验加反馈闭环，不承诺 100% 准确率，也不要把主流 AI 使用率当作项目能存活的证据。

DAG 编排（有向无环图编排） 是当前 agent 工作流平台常用的执行模型：把任务拆成若干节点，用有向无环图规定依赖顺序，节点可以是模型调用、工具调用或代码步骤。它的优势是可预测、可审计、易于并行；局限在于图结构是预先定义的，面对需要动态规划、循环重试或开放式探索的任务时表达力不足。这正是 Surendira 指出「管理式编排与 DAG 编排结合仍无法解决关键用例」的原因——真正提升确定性的做法，是在关键节点引入代码、SQL、机器学习等确定性组件，让模型负责判断、让程序负责执行。对提案筛查的启示是：如果说不清哪些步骤由模型决策、哪些由确定性代码兜底，风控就无从谈起。