AI Agent 到底是真趋势还是阶段性幻觉：从“会调用工具”到“会按SOP做事”的工作性判断

本文采用的是基于所列项目与资料的工作性理解，不是行业统一定义。我们的核心判断是：“AI Agent”不是单一能力名词，而是一组产品组织方式。 如果一个系统只是在聊天框里调用几个工具，它未必值得被当作 Agent；但如果它已经能围绕任务目标，按步骤理解问题、决定何时使用外部工具，并借助可复用的技能说明完成多步操作，那么它就不只是阶段性包装。[1][3][4][5]

先给结论：Agent 不是幻觉，但大量“Agent 叙事”可能是超前命名

从公开资料看，几家主要平台已经不再只讨论“模型回答得像不像人”，而是在补齐两类更工程化的能力：

1. 让模型决定何时使用工具。[1][3]
2. 让模型在复杂任务中，按可复用的程序性知识执行步骤。[1][5]

IBM 在其材料中将 AI agents 描述为：借助大语言模型理解用户输入，分步骤响应，并决定何时调用外部工具，用于软件设计、IT 自动化、代码生成、对话辅助等复杂任务。[3] Google Cloud 的公开页面则把 AI agent 与 AI assistant、bot 区分开来：agent 的描述重点是自主、主动、目标导向、多步骤行动，以及可独立做决策。[4]

这意味着，至少在产品定义层面，Agent 已经不只是“更聪明的聊天机器人”这个说法。[3][4]

但另一方面，把任何带工作流、带插件、带自动回复的系统都叫 Agent，也容易制造“阶段性幻觉”。原因在于：真正困难的部分不是接上工具，而是让模型在有限上下文里稳定地知道何时该做什么、按什么顺序做、做到什么程度停下。 而 OpenAI 与 Anthropic 近期都把“Skill”放到很重要的位置，恰好说明这个困难正在被正面工程化处理。[1][5]

一个更有用的区分：Agent 的问题不只是“能不能做”，而是“会不会做对”

本文的工作性理解里，判断 Agent 值不值得投入，可以先不问“它能接多少工具”，而先问三件事：

• 它是否围绕任务目标组织行为，而不只是围绕用户的一次提问组织回答？
• 它是否能在过程中决定何时调用外部工具？[1][3]
• 它是否拥有一套可复用、可被触发的程序性知识，而不只是临时提示词？[1][5]

如果前两项只有形式，第三项缺失，系统往往容易停留在演示阶段：看起来会规划，会调用 API，但一到真实业务场景就不稳定。

为什么 Skill 体系值得重视：它在补 Agent 最缺的一层

OpenAI Codex 的官方文档把 Skill 定义为一个目录结构，核心包含 SKILL.md，可选包含脚本、文档、资源和 openai.yaml 等内容。[1] 这不是一个抽象概念，而是一种明确的能力封装方式。

更关键的是，OpenAI 写明了 Codex 使用 Skill 的两种方式：

1. 显式调用：用户在提示中直接点名某个 skill；
2. 隐式调用：当任务与 skill 的 description 匹配时，Codex 可以自行选择该 skill。[1]

Anthropic 的 Claude Skills 文档也强调，SKILL.md 需要 YAML frontmatter，至少包含 name 与 description，并且 description 要同时说明 Skill 的功能以及何时使用它。[5]

这说明一个重要变化：平台不再只让开发者“给模型一个工具”，而是在要求开发者把使用工具的方法、适用条件、操作步骤和示例，封装成模型能检索和触发的知识单元。[1][5]

如果说“工具”解决的是连接问题，那么 Skill 更像解决执行问题。这个区分虽然在你给的材料里并非官方统一定义，但它与 OpenAI、Anthropic 的设计细节是相容的。[1][5]

Agent 之所以容易被误判，是因为“工具可用”常被误认为“能力成立”

很多团队在做 AI 应用、网站或小程序时，会先把外部系统接进来：搜索、数据库、CMS、工单系统、代码仓库、表单、支付状态、知识库……从工程上看，这当然重要。

但从 Agent 产品化角度看，只接通工具通常还不够。IBM 的表述里提到，AI agents 是在复杂任务中step-by-step 地理解和响应，并决定何时使用外部工具。[3] 这句话里的难点其实是“step-by-step”，而不是“external tools”。

OpenAI Codex 进一步暴露了真实约束：可用 skills 的初始列表进入上下文时，最多使用模型上下文窗口的 2%，或者在上下文窗口未知时最多 8,000 个字符；如果技能很多，会先缩短描述，更多时甚至可能省略部分 skills 并发出警告。[1]

这类细节很重要，因为它直接说明：

• Agent 的能力不是无限堆叠的；
• 技能不是装得越多越好；
• 触发条件、描述质量和信息密度，会影响 Agent 是否能“想到”该用哪一个 skill。[1]

所以，很多“Agent 不行”的印象，未必意味着方向错误，也可能只是因为产品还停留在“工具接入很多，但程序性知识组织很差”的阶段。

真趋势可能发生在这里：从提示词堆砌，转向“程序性知识组件化”

Anthropic 的文档把 Skill 的结构拆成至少两个层级：

• 启动时加载的元数据；
• 触发后再加载的指令内容。[5]

OpenAI 的文档也写得很清楚：初始阶段只给出可用 skills 的列表，但一旦某个 skill 被选中，Codex 仍会读取该 skill 完整的 SKILL.md 指令。[1]

这代表一种很现实的工程路线：不要把所有 SOP、边界条件、样例、脚本一次性塞进系统提示，而是把它们拆成按需启用的能力单元。

这件事对产品研发尤其关键，因为它把 Agent 从“提示词艺术”往“能力架构”推进了一步。对于网站后台、企业内工作台、小程序服务流程、客服辅助台、内容生产工具、代码研发助手等场景，这种方式有几个直接意义：

1. 可以把复杂流程拆成可维护模块

例如“发布文章到官网”这个任务，本来可能涉及：生成初稿、检查格式、补 SEO 字段、校验 slug、发布到 CMS、回写链接。若把这些步骤全部写在一个超长系统提示中，维护成本会快速上升。

按 Skill 思路，可以考虑拆成多个独立技能模块：

• 内容结构化技能
• SEO 字段检查技能
• CMS 发布技能
• 回滚与校验技能

这样更接近软件工程里的模块化，而不是一次性提示编排。

2. 可以降低上下文浪费

官方文档明确体现了“只在需要时读取完整技能说明”的做法。[1][5] 对真实应用而言，这意味着你不必让每次请求都背着全部业务知识跑。

3. 可以把“经验”沉淀成产品资产

当一个运营动作、审核动作、研发动作、数据录入动作反复出现时，把它写成 Skill，和把它留在某个同事脑中的“会用就行”状态，是两种完全不同的产品成熟度。

但为什么很多 Agent 项目仍会像幻觉？

本文的工作性理解里，至少有四类常见误判。

把“助手”误叫成“Agent”

Google Cloud 的页面明确区分了 AI agent、AI assistant、bot：assistant 偏向响应请求、提供信息、完成相对简单任务；agent 则被描述为更自主、主动、目标导向，并能执行复杂多步骤行动。[4]

这给产品团队一个实用提醒：

如果你的系统本质上仍然是“问一句、答一句；最多顺手调个接口”，那么把它定位为 assistant 可能更诚实，也更利于设计用户预期。

把“可调用工具”误叫成“可完成任务”

模型知道某个工具存在，不等于它知道什么时候该用、先用哪个、失败后怎么补救。[1][3]

Skill 文档要求写清“做什么”和“何时使用”，其实已经在间接回答这个问题。[5]

把“更多技能”误叫成“更强能力”

OpenAI 已经明确给出 skills 初始列表的上下文预算限制。[1] 这说明技能越多，越需要在命名、描述、分类和触发条件上做设计，否则模型甚至未必看得到全部能力。

把“自动化想象”误叫成“产品闭环”

IBM 和 Google Cloud 的描述都偏向复杂任务与多步骤执行。[3][4] 但在真实产品里，多步骤只是开始，闭环还包括：权限、确认、回退、异常处理、审计、结果可见性。这些往往决定项目是 demo 还是可上线能力。

对网站、小程序和企业后台团队，应该怎么判断要不要做 Agent

我们的建议不是“要么全面 Agent 化，要么完全不做”，而是用一个更保守的判断框架。

适合优先尝试的场景

可以考虑优先选择同时满足以下特征的任务：

• 步骤明确但语言输入不稳定：例如内容录入、商品信息归类、工单分派、页面配置建议、测试用例生成。
• 会频繁调用多个系统：例如 CMS、知识库、代码仓库、工单系统、内部配置平台。
• 存在可写成 SOP 的经验：即团队已经知道“通常怎么做才对”，只是执行成本高。
• 允许分阶段确认：并非一步到位全自动，而是关键节点让人确认。

这类任务更适合用 Skill 化方式，把经验变成可触发指令。[1][5]

不宜过早 Agent 化的场景

可以谨慎对待以下情况：

• 业务规则高度变化，SOP 尚未稳定；
• 真正的瓶颈在权限打通、流程审批或系统改造，而不是理解任务；
• 用户其实只需要快速查询与回答，不需要多步骤执行；
• 结果一旦出错代价很高，但你还没有校验、回退和人工复核设计。

这些场景中，先做 assistant、检索增强或普通工作流，可能更稳妥。

一个实用判断：先看“Skill 密度”，再谈“Agent 野心”

本文提出一个工作性概念：Skill 密度。它不是行业标准，只是一个便于产品讨论的观察维度。

所谓 Skill 密度，指的是：某个任务里，有多少关键步骤能够被清楚写成“何时使用 + 如何执行 + 示例/资源”的可复用单元。[1][5]

如果一个场景的 Skill 密度高，通常说明：

• 经验可沉淀；
• 步骤可复用；
• 模型更有机会稳定执行；
• 后续优化可以围绕单个技能进行。

如果 Skill 密度低，说明这个场景可能仍高度依赖临场判断、人际沟通、隐性知识或跨组织协调。此时硬做 Agent，容易得到“看起来很聪明，实际不稳定”的结果。

对研发实现的启发：别只设计工具协议，也要设计技能入口

从 OpenAI 和 Anthropic 的做法看，至少有三点研发启发值得直接采纳：[1][5]

1. 给每个能力写清楚“何时使用”

不仅要描述功能，还要描述触发条件。Anthropic 明确要求 description 同时包含 Skill 的功能及 Claude 应在何时使用它。[5]

2. 控制技能描述长度与区分度

OpenAI 已说明初始技能列表存在严格预算，技能过多时会缩短描述，甚至省略部分技能。[1] 这意味着 description 不是随便写的文案，而是实际影响调用率的产品接口。

3. 把高频失败点写进 Skill，而不是寄希望于模型“自己悟到”

如果一个任务常在某一步出错，可以考虑直接把检查顺序、异常分支、所需资源模板写入 SKILL.md 或配套资源中。[1][5]

安全与信任也说明了一件事：Agent 不是幻觉，但它确实更像“可执行软件”了

Anthropic 专门提醒：只使用来自可信来源的 Skills；恶意 Skill 可能通过指令和代码，诱导 Claude 以与其声明用途不符的方式调用工具或执行代码，并可能带来数据泄露、未授权访问等风险。[5]

这类安全警示非常值得重视，因为它说明 Skill 不再只是“提示词片段”，而更接近带执行后果的能力包。[5]

换句话说，Agent 之所以不像早期“智能插件”那样只是概念，恰恰是因为它已经开始碰到真正的软件问题：

• 能力发现
• 上下文预算
• 指令分层
• 工具调用策略
• 安全边界
• 依赖与资源组织

当一种技术开始系统性暴露这些工程问题时，它通常已经不只是营销修辞。

最后的工作性判断

本文的结论是：AI Agent 更像是真趋势中的早期产品形态，而不是纯粹的阶段性幻觉；但“所有 AI 应用都会变成 Agent”这一类泛化叙事，至少从现有资料看，并不能直接成立。

更准确的说法也许是：

• “会调用工具”并不足以证明 Agent 成立；[1][3]
• “能把程序性知识封装成可触发 Skill”更接近 Agent 的产品基础设施；[1][5]
• “是否值得做 Agent”，取决于你的任务是否具备可拆解的多步骤目标、可复用的 SOP，以及对上下文和安全边界的可控设计。[1][4][5]

如果你负责的是官网、内容平台、小程序、企业后台或垂直业务系统，我们的建议是：不要先问“要不要追 Agent 热点”，先问“我们有没有一批值得 Skill 化的高频任务”。

如果答案是有，那么 Agent 不是幻觉，而是一种值得逐步产品化的能力组织方式。