智能体（AI Agent）介绍
本文是「智能体」系列的开篇。与其把 Agent 简单理解成“接入了工具的大模型”，不如把它看成一个由模型、上下文、运行时、推理、记忆、工具和技能共同组成的执行系统。
本文重点回答几个问题：
- Agent 与普通聊天机器人、传统工作流有什么区别？
- AI Agent 是如何从“会回答”演进到“能完成任务”的？
- 一个现代 Agent 的完整架构包含哪些层？
- Agent 从接收用户目标到返回结果，要经过哪些步骤？
- ReAct、Workflow、Runtime、Harness Engineering 和 MCP 分别解决什么问题？
- 面对 LangChain、LangGraph、OpenAI Agents SDK、DeepAgents 等方案，应该如何选择？
一、为什么需要智能体：从“会回答”到“能完成任务”
大语言模型（LLM）擅长理解上下文、生成文本和进行推理，但模型本身并不等于一个完整的执行系统。它可以提出“应该查天气、读取文件或运行测试”，却需要外部运行时真正完成这些动作，并将结果再次反馈给模型。
因此，下面这些说法需要稍微修正：
| 常见说法 | 更准确的理解 |
|---|---|
| LLM 没有记忆 | 模型本身不会自动形成跨会话记忆，但应用可以通过上下文、会话状态、数据库或知识库提供记忆。 |
| LLM 不会使用工具 | 模型可以生成结构化的工具调用请求；工具的实际执行、权限控制和结果回传由运行时负责。 |
| LLM 只能单轮问答 | 只使用模型接口时通常是单轮生成；加入运行时后，可以形成多轮、多步骤的执行循环。 |
| LLM 输出不可控 | 幻觉和不稳定性仍然存在，但可以通过工具验证、结构化输出、评估、重试和人工审核降低风险。 |
Agent 的价值，不只是给模型增加“手和脚”，而是把模型放进一个可执行、可观测、可恢复的工作环境中。 模型负责理解目标和做决策，运行时负责调度工具、管理状态、处理错误，并决定何时暂停或结束。
Agent 的基本定义
可以用一句工程化的定义概括：
AI Agent 是一个以模型为决策核心，能够接收目标、使用上下文和工具，在运行时中循环执行并交付结果的系统。
这里的关键词是：目标、决策、工具、状态、反馈和执行。Agent 不一定完全自主，也不一定必须进行复杂规划；在高风险任务中，让人类在关键节点确认，反而是更可靠的设计。
二、智能体、大模型与传统程序的区别
| 维度 | 传统程序 | 大模型（LLM） | 智能体（Agent） |
|---|---|---|---|
| 本质 | 固定逻辑和确定性流程 | 参数化概率模型 | 模型与执行环境组成的系统 |
| 输入 | 结构化参数 | 自然语言或多模态输入 | 用户目标、上下文和环境状态 |
| 行为 | 按预先编排的路径执行 | 生成文本或结构化结果 | 根据当前状态决定下一步行动 |
| 工具 | 在代码中显式调用 | 只能描述要调用什么 | 选择工具，由运行时执行并回传结果 |
| 记忆 | 通常由程序显式管理 | 依赖当前上下文窗口 | 结合会话状态、长期记忆和检索系统 |
| 控制方式 | 程序员控制每一步 | 用户控制每一轮 | 运行时、策略和人工共同控制执行过程 |
| 失败处理 | 由代码预先定义 | 通常只返回一次结果 | 可以重试、回滚、反思、转交或请求人工介入 |
一句话总结：大模型是决策能力，传统程序是确定性执行，智能体是把两者放进同一套闭环系统。
三、智能体的演进：七个阶段
智能体的演进，不是简单地“模型越来越聪明”，而是模型能力、上下文组织、工具连接和运行环境逐步补齐的过程。可以按照能力跃迁分为七个阶段：
| 阶段 | 时间参考 | 核心问题 | 典型能力 |
|---|---|---|---|
| 提示词工程（Prompt Engineering） | 2018 年以前 | 如何让模型回答得更好？ | 通过提示词约束角色、格式和任务目标 |
| 上下文工程（Context Engineering） | 2018—2020 年 | 如何把正确的信息交给模型？ | 组装文档、知识库、历史对话、检索结果和工具结果 |
| 工具使用智能体（Tool-Using Agent） | 2021—2022 年 | 如何让模型采取行动？ | Function Calling、API、搜索、文件和数据库调用 |
| 工作流 / 编排智能体（Workflow Agent） | 2023—2024 年 | 如何可靠地执行复杂流程？ | DAG、状态图、条件分支、重试、回滚和人工介入 |
| Agent Runtime | 2025 年 | 如何让 Agent 稳定运行？ | 运行状态、记忆、计划、反思、工具和可观测性统一管理 |
| Harness Engineering | 2026 年 | 如何给 Agent 提供完整的工作环境？ | 权限、安全、验证、反馈、代码库规则和任务边界协同工作 |
| 自主进化智能体 | 2026 年以后 | 如何长期完成目标并持续改进？ | 长周期任务、自主规划、经验沉淀、协作和受控自我改进 |
其中，Harness Engineering 不是某个单独的模型或 SDK，而是一种面向 Agent 的工程方法：人类负责定义目标、约束和反馈机制，Agent 在明确的工具、权限、测试与验证环境中执行任务。
从“提示词”到“工作环境”的变化
早期关注点是“怎样写一条更好的提示词”；现在更重要的问题是：
- Agent 能否获得完成任务所需的上下文？
- 工具是否有清晰的边界、权限和输入输出约束？
- 任务是否可以暂停、恢复、重试和回滚？
- 结果是否能够通过测试、规则或人工审核验证？
- 运行过程是否可观测，出了问题能否定位原因？
这也是为什么现代 Agent 的竞争力，越来越取决于模型之外的系统设计。
四、智能体的核心架构：七层而不是五个孤立组件
传统介绍经常把 Agent 概括成“模型、规划、记忆、工具、行动”五个组件。这个概括适合入门，但在工程实践中还需要把上下文工程、运行时 / Harness 和技能层单独看出来。一个更完整的七层架构如下：
| 层级 | 模块 | 主要职责 |
|---|---|---|
| 1 | 基础模型（Foundation Model） | 理解、生成、推理和多模态处理，提供 Agent 的基础智能。 |
| 2 | 上下文工程（Context Engineering） | 组织系统提示词、用户输入、历史对话、检索内容、工具结果和任务约束。 |
| 3 | 运行时 / Harness（Runtime / Harness） | 管理执行循环、状态、权限、超时、重试、并发、暂停恢复和安全边界。 |
| 4 | 推理与决策（Reasoning） | 对目标进行拆解，选择下一步行动，依据反馈进行调整或反思。 |
| 5 | 记忆系统（Memory） | 管理短期会话记忆、长期知识、用户偏好、任务历史和检索增强（RAG）。 |
| 6 | 工具与连接层（Tools & MCP） | 连接数据库、API、文件系统、搜索引擎、浏览器及其他外部系统。 |
| 7 | 技能层（Skills） | 将领域知识、操作规范和可复用工作流封装成可调用的能力模块。 |
各层之间如何协作
一次典型执行可以抽象为：
1 | 用户目标 |
因此，Agent 不是一个“会自主思考的函数”，而是一个包含状态和执行边界的系统。模型可以更换，工具可以扩展，但运行时、权限、验证和可观测性决定了它能否真正进入生产环境。
五、Agent 如何工作：从输入到结果返回的完整闭环
前面的七层架构回答了“Agent 由什么组成”，运行流程则回答“这些组件如何在一次任务中协同工作”。完整流程不只是 ReAct 的“思考—行动—观察”，还包括上下文构建、结果验证、完成判断、安全控制和可观测性。
1. 主流程：九个步骤
一次完整的 Agent 运行，可以拆分为九个步骤：
| 步骤 | 阶段 | 主要工作 | 核心负责方 |
|---|---|---|---|
| 1 | 意图理解 | 识别用户意图，解析目标、约束和期望输出。 | Agent + LLM |
| 2 | 上下文构建 | 组装系统规则、对话历史、长期记忆、知识检索结果和环境状态。 | Runtime / Context Engineering |
| 3 | 规划与决策 | 基于当前上下文推理，决定下一步行动，必要时拆分任务。 | LLM |
| 4 | 执行动作 | 根据模型决策，调用 Skill 或 Tool，或者直接回答、追问、继续推理。 | Runtime |
| 5 | 观察结果 | 接收工具或技能的执行结果，包括成功数据、错误信息和环境变化。 | Runtime |
| 6 | 结果处理与验证 | 解析、过滤、校验和结构化执行结果，判断数据是否可信、完整。 | Runtime + Guardrails / Validators |
| 7 | 评估与判断 | 判断目标是否完成、结果是否可靠、是否还需要更多信息。 | LLM + Runtime 策略 |
| 8 | 生成最终回答 | 整合有效信息，生成自然语言、结构化数据或其他交付物。 | LLM |
| 9 | 返回结果 | 将答案交付给用户，并按需保存状态、记忆和运行记录。 | Agent / Application |
这里最重要的是第 7 步“评估与判断”：
- 如果目标已经完成，进入第 8、9 步，生成并返回最终结果；
- 如果目标尚未完成，则更新上下文，回到规划阶段，开始下一轮循环；
- 如果缺少必要信息，可以向用户追问；
- 如果遇到高风险操作、权限不足或无法自动处理的异常，可以暂停并请求人工介入；
- 如果达到时间、token、费用或最大循环次数限制，则由运行时终止任务并返回可解释的状态。
因此，Agent Loop 不是无限循环，而是一个受到完成条件、失败条件、资源预算和安全策略共同约束的状态循环。
2. ReAct 是运行循环的核心模式，但不是完整流程
ReAct（Reasoning + Acting）通常用于描述 Agent 内部的核心循环：
1 | Reason：根据目标、上下文和观察结果进行推理 |
它大致对应上图中的：
1 | 规划与决策（3） → 执行动作（4） → 观察结果（5） |
但生产级 Agent 不能只实现这三个动作。它还需要在循环前完成意图理解和上下文构建，在工具返回后进行结果验证，在循环结束后生成并返回答案。换句话说：
ReAct 描述的是 Agent 的局部决策循环，Runtime 描述的是保障整个任务从开始到结束的完整执行机制。
3. LLM、Agent、Runtime 与能力层如何分工
这几个概念容易混淆，可以按照职责区分：
| 组件 | 负责什么 | 不负责什么 |
|---|---|---|
| LLM | 理解、推理、规划、选择下一步行动、生成回答 | 不直接访问数据库、执行代码或改变外部系统 |
| Agent | 面向用户目标组织模型、上下文、记忆和能力，形成任务闭环 | 不等于某一次模型调用，也不等于某一个工具 |
| Runtime / Harness | 驱动循环、调度调用、管理状态、权限、预算、异常和暂停恢复 | 不替代模型完成语义推理 |
| Skill | 封装可复用的领域知识、操作步骤和工作流 | 不一定直接连接外部系统 |
| Tool | 执行数据库查询、API 调用、文件读写、代码运行等具体操作 | 不负责理解完整用户目标 |
| MCP | 标准化暴露、发现和连接工具或资源 | MCP 本身不是工具，也不自动保证工具安全可靠 |
| 外部系统 | 提供真实数据或接受操作，例如数据库、业务 API、文件系统和搜索服务 | 不参与 Agent 的规划与完成判断 |
例如，当用户要求“读取销售数据并生成分析报告”时，LLM 决定需要哪些数据；Runtime 校验调用是否合法；Tool 或 Skill 执行查询与分析；MCP 可以作为连接这些能力的标准协议；最终仍由 Agent 汇总结果并返回给用户。
4. 贯穿全流程的三类治理能力
完整运行流程还包含三组不属于某个单一步骤、而是贯穿始终的横切能力。
安全与控制
- 权限与访问控制：限制用户、数据和操作权限，遵循最小权限原则；
- Guardrails 与限制：进行内容过滤、敏感操作拦截、参数校验、超时和成本控制；
- 人工参与（HITL）：在付款、删除、发布、发送等高风险动作前进行审批或确认。
观察与监控
- 日志记录：保存模型请求、工具调用、响应、错误和状态变化；
- 指标监控：统计延迟、成功率、token、成本、循环次数和资源使用；
- 追踪与调试：通过 trace 还原每一步决策和调用链路，支持问题定位与回放。
评估与优化
- 效果评估：使用准确性、任务完成率、用户满意度和业务指标衡量质量；
- 提示词与 Skill 优化：根据失败案例改进指令、上下文组织和能力封装；
- 回归测试：建立固定测试集，防止模型、提示词、工具或工作流更新造成能力退化。
所以更准确的表达是：模型负责决策，Runtime / Harness 负责执行与治理，Skill 和 Tool 提供能力，MCP 提供标准化连接，外部系统承载真实数据与操作。
六、工具、MCP 与技能：Agent 如何连接外部世界
工具（Tools）
工具是 Agent 可以调用的外部能力，例如搜索、数据库查询、文件读写、代码执行、浏览器操作和业务 API。一个好的工具应该具备：
- 清晰、稳定的名称和参数 Schema；
- 明确的返回格式和错误信息；
- 最小必要权限；
- 幂等、超时和审计设计；
- 对危险操作提供预览或人工确认。
MCP（Model Context Protocol）
MCP 可以理解为一种连接标准：它让 Agent 通过统一的协议发现和使用外部工具、资源与提示模板，减少每个应用都重复编写连接适配器的工作。MCP 解决的是连接与发现问题，并不会自动解决权限、安全、数据质量或业务正确性问题。
技能（Skills）
技能位于工具之上，更接近“完成一类工作的能力”。例如“分析一份测试报告”可能会组合读取文件、运行脚本、查询缺陷系统和生成 Markdown 报告等多个工具。将这些步骤和领域规则封装成技能，可以让 Agent 复用成熟的工作方式，而不是每次从零规划。
七、主流框架与平台：按控制程度选择
截至 2026 年 8 月，可以从“控制程度”和“运行环境”两个维度理解常见方案：
| 方案 | 定位 | 适合场景 |
|---|---|---|
| LangChain | 模型、工具、消息和中间件等通用抽象 | 快速搭建 LLM 应用与标准 Agent |
| LangGraph | 面向状态图的 Agent 编排运行时 | 需要分支、循环、持久化、恢复和人工介入的复杂流程 |
| OpenAI Agents SDK | 提供 Agent、Runner、工具、Handoff、Guardrails 等原语 | 希望用较少抽象构建单 Agent 或多 Agent 应用 |
| DeepAgents | 面向复杂任务的深度智能体能力 | 任务分解、上下文隔离、子智能体和长任务执行 |
| Claude Code / Devin 等 Coding Agent | 以代码仓库和开发工具为工作环境的 Agent | 编码、测试、调试、提交和代码审查 |
| Dify / Coze 等平台 | 可视化工作流与 Agent 平台 | 快速验证业务想法、低代码交付 |
选择时可以遵循一个简单原则：
- 流程确定、分支清晰：优先使用普通代码或工作流，不必强行引入 Agent。
- 需要模型在有限范围内选择动作：使用 Tool-Using Agent 或 LangChain。
- 需要循环、持久化、暂停恢复和人工审核：使用 LangGraph 或其他明确的 Runtime。
- 需要长任务、子智能体和上下文隔离：考虑 DeepAgents 等深度智能体方案。
- 需要让 Agent 操作代码库或真实工作区：重点设计 Harness，而不只是选择模型。
八、智能体的应用场景
Agent 适合那些目标可以描述、行动可以授权、结果可以验证的任务：
| 场景 | 典型应用 | 关键控制点 |
|---|---|---|
| 知识问答 | 检索企业文档、汇总资料、回答问题 | 引用来源、检索质量、权限隔离 |
| 代码开发 | 修改代码、运行测试、提交变更、代码审查 | 沙箱、测试、差异审查、人工合并 |
| 数据分析 | 查询数据库、生成图表、解释指标 | SQL 权限、数据脱敏、结果校验 |
| 客户服务 | 查询订单、处理工单、转接人工 | 身份认证、操作授权、升级策略 |
| 办公自动化 | 整理邮件、生成文档、同步任务和日程 | 外发确认、敏感信息保护、审计 |
| 软件测试 | 生成用例、执行测试、分析失败日志 | 环境隔离、可重复执行、人工复核 |
| 多智能体协作 | 研究、规划、执行和审核分工 | 角色边界、通信成本、统一验收 |
九、挑战与展望
当前挑战
- 可靠性：多步执行会放大错误，需要计划、验证、重试和人工介入。
- 上下文管理：上下文并非越多越好，必须保持相关、最新且可追溯。
- 安全与权限：工具调用可能产生真实副作用，必须遵循最小权限和可审计原则。
- 成本与延迟：循环、检索和多智能体协作都会增加模型调用次数。
- 评估困难：Agent 的结果和过程都需要评估，单看最终文本往往不够。
- 长期任务管理：任务暂停、恢复、超时、回滚和环境变化仍然是工程难点。
未来趋势
未来的重点不会只是“让模型更会回答”，而是建设更完整的 Agent 工作环境：
- 更强的 Runtime / Harness：让任务可控、可观测、可恢复、可治理；
- 更好的上下文工程：自动选择信息，减少噪声和上下文污染；
- 更成熟的技能与协议生态：通过 Skills、MCP 等方式复用能力；
- 更可靠的人机协同：让人类负责目标、边界和验收，Agent 负责执行；
- 受控的长期自治：在明确权限和反馈机制下完成长周期任务，而不是无限循环。
结语
智能体的演进路线，可以概括为：
单次对话 → 工具调用 → 流程自动化 → 自主规划 → 协作智能 → 自我改进
理解 Agent，不能只盯着模型本身。真正决定系统能否落地的，是上下文是否准确、工具是否可靠、运行时是否可控、结果是否可验证，以及整个工作环境是否为 Agent 做了正确的设计。
后续文章将分别介绍 LangChain 系列、LangGraph 系列、DeepAgents 系列 与 Harness Engineering 系列 的具体实践。