调用一次大模型，就算 Agent 吗？

我前段时间反复遇到一个问题：很多人把"用了大模型""接了几个工具""整理了一套 Skills"，都直接叫作 Agent。

有一次，在一场关于 AI 工作流的讨论里，有人把一组为 Codex 整理的 Skills 合集称为"一个 Agent"。我当时就觉得不对劲：Skills 是工作方法和规范，还是能自己推进任务的运行单元？如果连这两层都没有分开，后面谈 Agent 架构只会越谈越乱。

后来聊到代码审查，又有人说：他有一个 Agent 项目调用 LLM 做代码审查，能输出审查结果和建议，并且自动触发流水线通知钉钉机器人。

我的第一反应是：这顶多是"接入了大模型的自动化流程"，为什么要急着给它戴上 Agent 的帽子？它有没有目标、状态、工具执行和下一步决策，还没说清楚，结论倒是先下了。

然后今年年初的时候，我还和一位国企总经理聊了聊 AI。他非常自信地说："大模型不就是搜索引擎吗？"

我当时就是这个表情。不是因为他必须懂一些 AI 的细节，而是因为他把一个涉及理解、生成、工具调用、外部执行和边界控制的系统，直接压扁成了"搜索"。在还没有了解能力边界之前，就用一句熟悉的话把结论下完，这种自信比单纯的不懂更让人警惕。

这几个场景看起来不同，问题其实一样：大家都在用同一个词，谈不同层的东西。有人说的是一份 Skills 文件，有人说的是一次模型调用，有人说的是一个能围绕目标持续行动的系统。

所以，我想把 Skills、Agent、Subagent 和 Harness 拆开讲一遍。这不是为了把术语说得更复杂，而是为了看清一个 AI 项目究竟多做了什么：哪些能力是真的，哪些只是换了个名字。

无论你把 AI 看成泡沫还是机会，都得先把它能做什么、不能做什么弄清楚。而真正能拉开差距的，从来就不是"谁先接了多少个模型 API"，而是谁能把模型、工具和业务流程组合成一个可靠的系统。

所以，这篇文章只回答一个问题：

一个项目，到底凭什么叫 Agent？

先从一个任务开始：修复移动端 Bug

假设我对 Codex 说：

"请修复这个页面在手机上的布局溢出问题，跑测试，确认没问题后提交代码。"

如果背后只是一次模型调用，流程可能是：

用户问题 -> 调用 LLM -> 返回一段建议或代码

模型也许会告诉我检查 overflow、容器宽度和媒体查询，但它不会自动打开仓库、修改文件、运行测试，更不会看到测试失败后继续修复。

这和接入 OCR、支付或搜索服务没有本质区别：应用把请求发给第三方服务，拿到结果，再由代码决定下一步。

所以，调用了 LLM API，只能说明项目使用了模型能力，不能直接说明它是 Agent。

Agent 到底多做了什么

在这里，我把 Agent 理解为一个围绕目标持续推进任务的运行单元，而不是一个"回答得更像人"的聊天框。

同一个修 Bug 任务，如果系统允许模型查看文件、修改代码、运行测试，并根据结果决定下一步，它可能会这样工作：

理解目标
  -> 查看项目结构
  -> 找到相关组件
  -> 读取 CSS 和测试
  -> 修改文件
  -> 运行测试
  -> 根据失败信息继续修改
  -> 汇报结果

关键变化不在于调用了几次模型，而在于模型能不能根据当前结果做出下一步选择。它可以决定先读哪个文件、要不要运行测试、测试失败后改哪里，以及什么时候算完成。

可以把 LangChain 的 create_agent 理解成一种 Agent runtime：它把模型调用、工具调用和循环封装起来。它不是一个新模型，也不是把模型重新训练成了 Agent。

from langchain.agents import create_agent

agent = create_agent(
    model,
    tools=[read_file, edit_file, run_tests]
)

result = agent.invoke({
    "messages": [
        {"role": "user", "content": "修复移动端页面溢出并运行测试"}
    ]
})

如果只调用一次 llm.invoke()，哪怕这个函数名字叫 review_agent，它仍然只是一次模型服务调用。名字不会自动改变架构。

Skills 是什么：一份可复用的做事方法

继续看修 Bug 的任务。

我可以给 Agent 一份前端排错 Skill，里面写清楚：先看哪些文件、如何启动项目、什么时候截图、要跑哪些测试、最后怎样记录结果。

它可能长这样：

frontend-debug/
  SKILL.md          # 适用场景、步骤和判断规则
  scripts/          # 启动项目、截图、收集日志
  references/       # 团队规范和框架文档
  templates/        # Bug 报告和验收模板

Skill 像一本针对特定工作的操作手册，也像一份可以被 Agent 加载的工作流规范。它把经验、脚本和资料打包起来，让不同的人、不同的 Agent 都能按同一套方法做事。

但 Skill 本身通常不会接收用户目标，也不会自己决定调用哪个工具，更不会负责保存状态、处理权限或维护循环。

因此，单纯整理一组供 Codex 使用的 Skills，本质上是一套可复用的工作方法和规范，更准确地说是"Agent 能力包"，而不是一个 Agent。只有当它背后还配套了独立的模型决策循环、工具执行和状态管理机制时，整个系统才可以称为包含一个 Agent。

Subagent 是什么：被主 Agent 委派的另一个 Agent

Subagent 最容易被误解成"又调用了一次 LLM"。其实它首先是一种关系：有一个主 Agent，把边界清楚的任务交给另一个独立 Agent。

比如，主 Agent 负责修复代码，它可以说：

"请 Code Reviewer 检查这次修改，读取相关文件，运行测试，列出严重问题和证据。"

这里的 Reviewer 如果有自己的指令、工具、上下文和停止条件，能够独立完成检查，再把结构化结果交回主 Agent，通常才可以称为 Subagent。

而下面这种写法通常不是 Subagent：

def review_code(diff: str) -> str:
    return llm.invoke(f"请审查下面的代码变更：\n{diff}")

它只是一个封装了 LLM API 的函数。它可以叫"代码审查器"，也可以作为主 Agent 的工具，但它没有自己的 Agent loop。

OpenAI Agents SDK 支持两种常见的多 Agent 关系：主 Agent 把专业 Agent 当作工具调用，主 Agent 保留最终回答权；或者通过 handoff 把控制权交给专业 Agent，由它继续处理任务。OpenAI Agents SDK Agents

所以，判断 Codex 调用的 Code Reviewer 是不是 Subagent，不要看它是不是另一个 API，也不要看它的名字，而要看四件事：

1. 它是不是一个独立配置的 Agent；
2. 它有没有自己的工具和上下文；
3. 它能不能独立循环推进审查任务；
4. 它是不是被主 Agent 明确委派，并返回结果或接管对话。

Harness 是什么：让 Agent 真正跑起来的外层系统

如果 Agent 是负责决定下一步的人，那么 Harness 就是它工作的整套环境和规则。

在修 Bug 的例子里，Harness 负责的可能是：

• 把正确的仓库目录交给 Agent；
• 限制它只能读写指定文件；
• 在沙箱里运行测试和脚本；
• 控制网络、密钥和系统权限；
• 保存消息、工具调用和中间结果；
• 设置超时、最大循环次数和重试规则；
• 在提交代码前要求人工确认；
• 记录日志，并在中断后恢复任务。

模型只负责提出下一步建议。它说"请运行测试"，并不等于测试真的被运行了。真正执行命令、把结果放回上下文、检查权限和决定是否继续的，是外部运行层。

OpenAI 对 Codex Harness 的介绍，提到的正是这类能力：Agent loop、线程持久化、配置认证、工具执行、沙箱以及 Skills 接入。Unlocking the Codex harness

因此，Harness 不是"大模型的另一个名字"，也不是一份 Prompt。它更像连接模型、工具、状态和真实环境的控制层。

create_agent、Agent 和 Harness 怎么放在一起

这几个概念可以这样理解：

Harness
  -> Agent runtime
       -> 主 Agent：理解目标，决定下一步
       -> Subagent：被委派的独立 Agent
       -> LLM：生成判断和工具调用意图
       -> Tools：文件、数据库、搜索、业务 API
       -> Skills：提供某类任务的步骤、资料和脚本

create_agent 主要提供 Agent runtime，也就是模型和工具之间的循环。一个生产系统还需要权限、沙箱、状态、审计、重试、人工审批和失败恢复，这些共同构成更完整的 Harness。

Skills 是 Agent 可以按需加载的工作方法。Subagent 是 Agent 之间的委派关系。它们不是同一层的概念，也不能因为放在同一个代码仓库里就互相替代。

用一个 Code Reviewer 场景把边界再走一遍

假设 Codex 正在修改代码，完成后需要做审查。

第一种情况，Codex 把 diff 发给一个 API，API 返回几条意见。这里是"Agent + 一个 LLM 工具"，这个 API 通常不是 Subagent。

第二种情况，Codex 把审查任务交给一个独立 Reviewer Agent。Reviewer 自己读取文件、运行测试、检查规范，最后返回报告。这种情况下，才更符合 Subagent 的定义。

第三种情况，Reviewer 需要在隔离目录运行测试，不能访问生产密钥，失败后可以从检查点恢复。提供这些能力的外层系统，就是 Harness。

第四种情况，团队又写了一份 code-review/SKILL.md，规定审查顺序、严重级别和报告格式。这是 Skill，负责把方法固定下来。

同一个 Code Reviewer 功能，可以同时拥有 Skill、Agent、Subagent 和 Harness，但它们承担的责任不同。

不要用"调用了模型"判断是不是 Agent

判断一个系统是不是 Agent，直接对照下面的五个问题：

1. 系统有没有一个需要持续推进的目标？
2. 模型能不能根据当前结果选择下一步？
3. 它有没有真正执行工具或外部动作？
4. 动作结果会不会回到模型，形成循环？
5. 如果存在多个 Agent，是否有清楚的委派或接管关系？

如果只是"输入一段文本，调用一次 LLM，返回一段文本"，它是 LLM 应用。

如果步骤由代码固定，只是中间接入了 LLM、OCR、搜索或支付，它是 LLM 增强的业务流程。

如果模型能围绕目标选择工具、读取结果、继续行动，并在边界内结束任务，它才更接近 Agent。

如果还有一个独立 Agent 被主 Agent 委派，通常才可以称为 Subagent。

如果系统还负责上下文、状态、权限、沙箱、重试、审计和恢复，那才有了完整的 Harness。

这几个概念一旦分清，很多争论会简单很多：我们讨论的到底是模型能力、工作流方法、Agent 决策，还是运行控制系统？