Agent到底比一次大模型调用多了什么？小白从这张流程图看懂

模型像一个一次性接单的顾问：你给材料，它给答案。Agent更像带工作台的执行者：它能保留任务状态、选择工具、操作文件、遇到失败后继续。OpenAI在9月10日发布Agents API公开测试，正好让我们看清一个常见误区——Agent不是“更会聊天的模型”，而是模型外面的一整套运行系统。

先分清三个东西

普通模型调用最简单：输入一段内容，得到一段输出。适合摘要、分类、抽取和单轮生成。

固定工作流像工厂流水线。开发者提前写好步骤，例如先检索、再生成、最后检查格式。模型可以参与某一步，但不能自由改变流程。这种方案更可控、容易测试，很多业务其实到这里就够了。

Agent面对的是目标，不是固定的每一步。它可能先观察环境，再决定使用哪个工具，根据结果继续规划；任务跨越较长时间时，还要保存中间状态并从失败处恢复。

生活类比是：模型是咨询窗口，工作流是固定办事流程，Agent是拿到目标后能在多个窗口之间跑手续的办事员。但类比的边界也很明确：今天的Agent没有人的责任意识，它只是依据模型输出和程序规则选择下一步，仍可能误解目标或调用错误工具。

准确一点：Agent等于模型加运行支架

OpenAI称Agents API提供支撑Codex的托管Agent Harness。Harness可译为“运行支架”或“执行框架”，负责管理上下文、工具、长期会话和子Agent协调。开发者还要选择执行环境：OpenAI托管沙箱、自有基础设施或合作方沙箱。

flowchart TD
    A[用户给出目标] --> B[Agent会话保存状态]
    B --> C[模型判断下一步]
    C --> D{是否需要工具}
    D -- 否 --> E[生成阶段结果]
    D -- 是 --> F[在受控环境调用工具]
    F --> G[观察工具返回]
    G --> C
    E --> H{任务是否完成}
    H -- 否 --> C
    H -- 是 --> I[交付结果与证据]

这张图里，模型负责判断，Harness负责让判断安全、连续地落地。工具让Agent接触外部世界，环境决定代码和文件在哪里运行，会话则保存跨步骤状态。缺少其中任何一层，都可能只是一次带工具提示的模型调用，而不是可靠的长期Agent。

“会话”也不是把全部历史无限塞回模型。长期任务会产生大量网页、日志和工具输出，如果每一步都原样保留，成本与上下文噪声会持续增长。运行支架通常需要压缩旧过程、保留关键状态，并让原始证据仍可追溯。压缩错了，Agent可能忘记约束；什么都不压缩，它又可能在信息堆里找不到目标。这正是Agent工程区别于一次聊天调用的地方。

一个最小会话骨架

下面依据官方发布示例精简，只展示创建会话的结构，不接工具，也不给执行环境权限。Agents API仍处公开测试，运行前应以最新参考文档核对SDK版本和字段。

npm install openai
<span>export</span> OPENAI_API_KEY=<span>"你的密钥"</span>

<span>import</span> <span>OpenAI</span> <span>from</span> <span>"openai"</span>;

<span>const</span> client = <span>new</span> <span>OpenAI</span>();

<span>const</span> session = <span>await</span> client.<span>beta</span>.<span>agents</span>.<span>sessions</span>.<span>create</span>({
  <span>agent</span>: {
    <span>model</span>: <span>"gpt-6-astra"</span>
  },
  <span>environment</span>: {
    <span>type</span>: <span>"none"</span>
  },
  <span>input</span>: <span>"把一周的开发记录整理成三个风险和三个下一步。"</span>
});

<span>console</span>.<span>log</span>(session.<span>id</span>);

这个示例使用环境变量中的密钥，只创建会话，不代表Agent可以读取你的开发记录；真实应用还要安全地提供数据或工具。由于本次任务没有调用远端API，示例未实际运行，不能把它当作已验证的生产代码。

小白最容易踩的四个误区

Agent等于模型更聪明。 同一个模型配上不同工具、权限和恢复机制，可靠性可能完全不同。
工具越多越好。 工具越多，选择错误、权限过大和提示词攻击的表面也越大。
有记忆就不会丢上下文。 状态保存、检索和重新注入仍需要工程设计。
Agent会对结果负责。 它不会承担业务责任，高风险动作仍需审批、日志和回滚。

Agent适合跨步骤研究、代码修改、文件处理和需要根据反馈改变路线的任务。不适合规则确定的支付计算、权限判定和必须严格可重复的核心逻辑；这些场景优先使用普通程序或固定工作流。

判断是否需要Agent，可以问三个问题：步骤能否在开发前完全列出？中间结果是否会改变下一步？任务失败后是否需要从检查点继续？如果步骤固定、输入输出稳定，普通程序更便宜可靠；如果需要观察环境并动态选路，Agent才开始显示价值。不要因为“Agent”更热门，就把三步确定流程包装成不可预测的自主系统。

我的判断与实践题

Agents API降低的是运行Agent的基础设施门槛，不是业务定义门槛。开发者少写了会话、环境和编排代码，却仍要回答：它能访问什么、何时必须停下、错误如何恢复、最终结果由谁确认。真正成熟的Agent产品，往往不是自主程度最高，而是边界最清楚。

五分钟实践题：把示例任务改成“检查一个目录中的Markdown格式”，列出Agent真正执行前需要的三个工具权限，以及哪一步必须由人确认。不要急着写代码，先画出允许和禁止的动作。

你的业务真的需要Agent，还是一个可测试的固定工作流已经足够？

关注「蜗牛聊AI」，一起看懂技术变化背后的真正机会。

本文首发于 java4u.cn，转载请注明出处。