AI Agent（智能体）

AI Agent（智能体） 是一种能够自主感知环境、制定计划、调用工具、执行多步骤任务的 AI 系统。区别于单次问答的 LLM 调用——Agent 有持续的工作目标，能在多轮循环中做决策、调整方向、直到任务完成或遇到无法处理的情况。

OpenAI 的《A practical guide to building agents》给出一个更面向产品工程的边界：Agent 是能代表用户独立完成任务的系统，而不是任何接了 LLM 的应用。简单聊天机器人、单轮 LLM 调用、情感分类器这类系统，即便使用了大模型，也不是 Agent；关键差别在于 LLM 是否参与工作流执行控制，能否根据状态选择工具、判断完成、失败时纠偏或把控制权交还给人。

Agent 与普通 LLM 调用的区别

维度	普通 LLM 调用	AI Agent
生命周期	单次请求-响应	多轮循环，持续执行
工具使用	无或有限	可调用外部工具、读写文件、操作系统
记忆	仅当前上下文	可接入Agent Memory（Agent 记忆）（文件、数据库、看板）
决策自主性	无，由人决定下一步	能自主决定下一步行动
目标导向	回答当前问题	持续追踪并完成目标

常见误解：Agent 真的在自主规划吗？

很多人以为的 Agent：给一个目标（如"帮我出一份竞品调研报告"），AI 就会自己思考调研维度、自己去搜信息、自己分析对比、自己排版输出。

但事实上，越是"好用、靠谱"的 Agent，背后往往越是传统软件工程的胜利，而不是 AI 自主规划能力的体现。那些"调研步骤"不是 AI 想出来的，而是工程师事先写死在代码流程图里的。AI 只是镶嵌在软件流水线上的工具，在特定子步骤里扮演"填空"的角色。

所以真正决定 Agent 上限的，更多是工程师的软件工程水平、业务流程设计，乃至组织架构与人机协同的深度，而不是 AI 大模型本身。Agent 越好用，越依赖 CPU 上的确定性代码，而不是 GPU 上昂贵的模型算力。

更精确的工程公式是：Agent = Model + Harness Engineering（驾驭工程）。Model 负责推理和决策；Harness 则把系统提示、工具、执行环境、持久状态、编排、权限与验证组织成可运行系统。只有前者是一次模型调用，二者结合才构成能持续行动的 Agent。

核心组件

感知（Perception）：读取环境状态——文件、代码、CI 结果、Issue、日志
规划（Planning）：根据目标和当前状态，决定下一步行动
工具调用（Tool Use）：执行代码、读写文件、调用 API、搜索信息
记忆（Memory）：通过Agent Memory（Agent 记忆）跨轮次保存状态，避免遗忘已完成的工作
反思（Reflection）：评估行动结果，调整计划

这些组件在工程实现中通常被组织为 Agent Loop（智能体循环）：模型先根据 prompt 推理；如果需要工具，harness 执行工具并把观察结果追加回输入；循环直到模型返回 assistant message。对软件 Agent 来说，assistant message 只是 turn 的结束信号，真正的产出往往是已经写入工作区的代码和文件。

OpenAI guide 用一个更小的实现三件套描述 Agent：模型（Model） 负责推理和决策，工具（Tools） 连接外部系统并执行动作，指令（Instructions） 规定行为流程与边界。实践上可以先用最强模型做原型和 eval 基线，再逐步把简单子任务换成更小、更低延迟的模型。

OpenAI 2025 年 3 月发布的 Agent 工具栈把这组三件套进一步平台化：Responses API（响应 API）承载模型调用和内置工具，Web search、File search、Computer-Using Agent等工具连接外部世界，OpenAI Agents SDK负责多 Agent handoff、guardrails 和 tracing。这个分层说明：Agent 产品的核心不是单个 prompt，而是模型、工具、编排和可观测性共同组成的系统。

GPT-Live展示了同一分层在语音产品中的一种形态：前台语音模型持续负责听、说和轮次互动，耗时的搜索、推理或更复杂的 Agent 工作则可委派给后端前沿模型。实时交互与深度执行解耦后，用户不必在每个复杂任务期间失去对话反馈；但后端工具权限、结果校验和安全策略仍需按完整 Agent 系统来治理。

Anthropic 的 Claude Agent SDK则从另一个方向平台化 Agent：把 Claude Code 已经产品化的文件读写、Bash、代码搜索、编辑、Hook、权限、session、MCP 和 subagent 能力做成 Python / TypeScript 库。它说明 Agent SDK 不一定从“模型 API + 函数调用”出发，也可以从一个成熟的交互式 Agent 产品向生产应用内嵌形态延伸。

flowchart LR
    输入[输入] --> 指令

    subgraph 智能体[智能体]
        direction TB
        指令[指令] --> 工具[工具] --> 护栏[护栏] --> 钩子[钩子]
    end

    钩子 --> 输出[输出]

    style 护栏 stroke-dasharray: 5 5
    style 钩子 stroke-dasharray: 5 5

Workflow vs. Agent 的架构区分

Anthropic 在《Building Effective Agents》中给出了一个重要的架构分类：并非所有 Agentic System 都是真正的"Agent"。

类型	定义	特点
Workflow（工作流）	LLM 和工具通过预定义代码路径编排	可预测、适合定义明确的任务
Agent（智能体）	LLM 动态指导自身的流程和工具使用	灵活、适合开放性问题

这一区分很重要：很多被称为"Agent"的系统，实际上是 Workflow——流程由工程师预先设计，LLM 只在特定节点填空。在这两者之间，还有五种具体的工作流编排模式，见 Agentic System Patterns（智能体设计模式）。

多 Agent 架构

复杂任务通常拆分给多个专职 Agent：

实现 Agent：编写代码、执行修改
Review Agent：审查产出质量，防止 Agent 审自己的产出（等于让学生自己批卷）
测试 Agent：运行并验证测试
协调 Agent（Orchestrator）：分配任务、汇总结果、决定下一步

多 Agent 并行时需要Loop Engineering（循环工程）和Agent Worktree（Agent 工作树），避免相互污染。

更高一层的 Dynamic Workflows（动态工作流）则把多 Agent 协作从“临时分派任务”推进到“先生成可执行编排脚本，再由 Runtime 调度团队执行”。在这种形态里，Agent 不只是执行者，也可以承担流程规划、任务分配、状态复核和结果验证等类似 FDE 或技术负责人式的组织职责。

ACI：工具接口是 Agent 的 UI

Agent 的可靠性不仅取决于 prompt 质量，也取决于工具接口的设计质量。Agent-Computer Interface（智能体计算机接口）是这一设计维度的系统化方法论——类比 HCI（Human-Computer Interface），把工具定义、参数命名和文档视为 Agent 的"用户界面"，需要同等的设计投入和测试。

物理 Agent 也遵循同一规律，只是接口从 API 参数变成力矩、控制器代码、预训练策略和感知工具。Anthropic 的机器人控制实验表明，接入 Vision-Language-Action Model（视觉-语言-动作模型）或预训练步态后，通用模型的可行动能力会远高于直接关节控制。此时“Agent 能做什么”取决于完整控制栈和权限，而不只是模型本身。

关键风险

错误累积（Error Compounding）：Hallucination（幻觉），无法保证每步推理正确。单步 90% 准确率（已是顶尖模型）的 Agent 在执行 20 步任务时，整体正确率只有 0.9²⁰ ≈ 12%——第一步的小偏差被后续步骤当作事实基础，错误像雪球一样放大
“完成"不等于完成：Agent 汇报任务完成不代表结果正确，必须独立验证
工具误用与权限越界：Agent 可以通过工具产生真实副作用，必须用 Agent Guardrails（Agent 护栏）、权限边界和人工审批约束高风险动作
Comprehension Debt（理解债）：Agent 生成内容越快，人越可能不理解它在做什么
成本失控：长期运行的 Agent 会持续消耗 Token，需主动控制上下文大小和运行频率
Context Rot（上下文腐烂）：所有模型随输入增长而退化；100+ 轮次后可能发生上下文漂移

Harness 是可靠性的绑定约束

近期实证表明：仅修改 Agent 执行基础设施（harness）而不改动模型权重，可在编程 benchmark 上获得高达 10× 的提升，超过典型模型升级带来的 2–4pp 改进。这一"绑定约束论题"意味着 Agent 可靠性工程的主要杠杆在于Harness Engineering（驾驭工程），而非模型本身。

ETCLOVG Taxonomy（ETCLOVG 分类法）将 Agent harness 系统化为七层：执行环境（Agent Sandbox（Agent 沙箱））、工具接口（Model Context Protocol（模型上下文协议））、Context Engineering（上下文工程）、生命周期编排、可观测性、验证与治理。