1.智能体-Agent与Harness

1.Agent

1.1 理论模型

2023 年 6 月 23 日，翁丽莲（Lilian Weng，时任 OpenAI 应用研究主管）在其经典博客《LLM Powered Autonomous Agents》中系统阐述了现代 Agent 的核心思想。这篇博客被认为是 Agent 领域的奠基性文献之一，为后续的研究和工程实践提供了清晰的理论框架。

她提出了一个被后续整个行业反复引用的公式：
Agent = LLM + Planning + Memory + Tool Use

这个公式简洁地概括了现代 Agent 的四个核心组成部分：

1. LLM（大语言模型）：作为 Agent 的"大脑"，负责理解用户意图、生成推理步骤和决策。LLM 提供了基础的认知能力，但单独使用 LLM 还不足以构建一个完整的 Agent 系统。

2. Planning（规划）：Agent 需要能够将复杂任务分解为可执行的子任务序列。规划能力使 Agent 能够思考"如何"完成任务，而不仅仅是"回答"问题。例如，当用户要求"帮我分析上个月的销售数据并生成报告"时，Agent 需要规划出：获取数据 → 清洗数据 → 分析趋势 → 生成可视化 → 撰写总结等多个步骤。

3. Memory（记忆）：Agent 需要记住过去的交互、学习到的知识和任务状态。记忆分为短期记忆（当前会话的上下文）和长期记忆（跨会话的持久化存储）。这使得 Agent 能够进行连续的、有上下文的对话，而不是每次交互都从零开始。

4. Tool Use（工具使用）：Agent 能够调用外部工具来扩展其能力边界。这些工具可以是搜索引擎、数据库查询、代码执行器、API 调用等。通过工具使用，Agent 能够执行超出纯文本生成范围的实际操作。

这个理论模型的重要性在于它明确了 Agent 不仅仅是"更聪明的聊天机器人"，而是一个具备自主性、持续性和行动能力的系统。它从"被动响应"转向"主动执行"，从"单次交互"转向"持续协作"。

1.2 理论工程化

翁丽莲的框架更偏向理论模型，它告诉我们一个 Agent"应该具备什么能力"。但真正把 Agent 部署到生产环境，会遇到一连串工程问题：

• 上下文窗口会溢出，如何压缩与组织？：LLM 的上下文长度有限（如 128K），而 Agent 任务可能涉及大量历史对话、文档内容和工具调用结果。需要智能的上下文管理策略，如关键信息提取、摘要生成、分层存储等。

• 长期记忆如何持久化？跨会话如何恢复？：用户希望 Agent 能记住几周甚至几个月前的对话和偏好。这需要设计可靠的数据存储方案、高效的检索机制和隐私保护策略。

• 工具越来越多，如何标准化扩展？：一个成熟的 Agent 系统可能需要集成数十甚至上百个工具。需要统一的工具描述格式、自动发现机制、权限管理和错误处理。

• 模型执行到一半崩溃了，状态如何保存和恢复？：复杂的 Agent 任务可能运行数小时，中间可能遇到网络中断、服务重启等问题。需要类似数据库事务的检查点机制。

• 工具会执行危险命令，如何隔离与授权？：当 Agent 能够执行代码、操作数据库或调用外部 API 时，必须考虑安全沙箱、权限控制和审计日志。

为了解决这些问题，工程界在原始框架之上逐步增加了大量生产级核心组件：Prompt 工程化、Function Call、MCP、Context 管理、Checkpoint、Agent Loop、Runtime…… 最终形成了 OpenClaw / Hermes / DeepAgents 所代表的现代 Agent Harness。

tips: 翁丽莲的博客提出了 Agent “要有什么能力”，Harness 解决的是这些能力 “如何在生产环境中可靠地跑起来”。可以这样理解：理论模型定义了 Agent 的"功能规格"，而工程化实现了这些功能的"生产部署"。

工程化的关键转变

1. 从静态提示到动态提示工程：不再是一成不变的系统提示词，而是根据任务状态、用户历史、工具可用性动态生成最有效的提示。

2. 从简单工具调用到工具编排：工具之间可能存在依赖关系，需要智能的调度和并行执行优化。

3. 从内存管理到状态管理：将 Agent 的思维状态、工具调用历史、用户偏好等统一建模和管理。

4. 从单次执行到生命周期管理：支持任务的暂停、恢复、取消、重试等完整生命周期操作。

这些工程化组件使得 Agent 从实验室原型转变为能够处理真实业务场景的可靠系统。

1.3 现代Agent

Agent = Model + Harness

现代 Agent 架构可以概括为这个简洁的公式，它反映了从理论到实践的演进：

Model（模型层）

模型层是 Agent 的智能核心，通常基于大语言模型构建，但已经超越了原始的 LLM：

1. 基础模型：如 GPT-4、Claude、Gemini 等，提供基础的语言理解和生成能力。

2. 专业模型：针对特定领域优化的模型，如代码生成、数学推理、多模态理解等。

3. 模型编排：根据任务类型智能选择最合适的模型，平衡成本、速度和准确性。

4. 思维链优化：通过 CoT（Chain-of-Thought）、ToT（Tree-of-Thought）等技术提升复杂推理能力。

Harness（框架/装备层）

Harness 是将模型能力转化为可靠服务的基础设施，相当于 Agent 的"操作系统"：

1. 执行引擎（Runtime）：负责调度模型调用、工具执行、状态管理等核心流程。

2. 工具管理：

   • 工具注册与发现：自动识别可用工具及其功能
   • 权限控制：基于角色的工具访问权限
   • 错误处理：工具调用失败时的降级和重试策略

3. 记忆系统：

   • 短期记忆：当前会话的上下文管理
   • 长期记忆：向量数据库、图数据库等持久化存储
   • 工作记忆：任务执行过程中的临时状态

4. 安全与监控：

   • 输入输出过滤：防止提示注入、数据泄露
   • 执行沙箱：隔离危险的工具操作
   • 审计日志：完整的操作记录用于调试和合规

5. 可观测性：

   • 实时监控 Agent 的执行状态
   • 性能指标收集（延迟、成功率、成本等）
   • 可视化调试工具

现代 Agent 的特点

1. 模块化设计：各个组件可以独立升级和替换，如更换模型提供商、添加新工具等。

2. 可扩展性：支持水平扩展以处理高并发请求，支持垂直扩展以处理复杂任务。

3. 可靠性：具备故障恢复、状态持久化、限流降级等生产级特性。

4. 易用性：提供清晰的 API、丰富的 SDK 和可视化配置界面。

5. 生态集成：与现有的开发工具、部署平台、监控系统无缝集成。

实际应用示例

以客服场景为例，现代 Agent 的工作流程可能是：

1. 用户输入问题 → 2. Agent 理解意图并规划解决步骤 → 3. 查询知识库获取产品信息 → 4. 调用订单系统检查用户状态 → 5. 生成个性化回复 → 6. 记录交互历史用于后续优化

这个过程中，Model 负责第 2、5 步的理解和生成，Harness 负责第 3、4 步的工具调用和第 6 步的记忆管理，两者协同完成端到端的任务。

现代 Agent 不再是简单的"问答机器"，而是能够自主规划、使用工具、持续学习、可靠执行的智能系统，正在改变软件开发和业务自动化的范式。

2. Agent 核心组件

在从理论模型（Agent = LLM + Planning + Memory + Tool Use）演进到现代工程化架构（Agent = Model + Harness）的过程中，一系列核心组件被提炼和标准化，构成了现代 Agent 系统的基石。这些组件解决了将 Agent 从原型推向生产所面临的关键工程挑战。

2.1 Prompt 系统

Prompt 系统是现代 Agent 的“指令集”和“思维引导器”，它已从静态文本演变为一个动态、可编程的子系统。

• 动态提示工程：系统提示词不再是固定的字符串，而是根据任务上下文、用户身份、可用工具和历史交互动态生成的模板。例如，在客服场景中，系统会根据用户问题的复杂度和历史记录，动态注入不同的解决策略和知识库查询指令。
• 提示模板与变量：支持参数化模板，如 {user_name}、{current_date}、{available_tools}，在运行时被具体值替换，实现高度的个性化和情境化。
• 少样本学习（Few-Shot）与思维链（CoT）集成：Prompt 系统内置了示例选择机制，能根据当前问题自动从示例库中检索并插入最相关的 Few-Shot 示例，或引导模型进行分步推理（CoT）。
• 安全与护栏（Guardrails）：集成输入/输出过滤器，防止提示注入攻击（Prompt Injection），确保用户输入和模型输出符合安全策略与业务规则。

2.2 Function Call（工具调用）

Function Call 是 Agent 与外部世界交互的标准化接口，它将自然语言指令转化为可执行的操作。

• 标准化描述与发现：工具（函数）通过统一的 Schema（如 OpenAPI Spec、JSON Schema）进行描述，声明其名称、参数、返回值及用途。Agent 框架能自动发现并编目所有可用工具。
• 意图识别与参数提取：模型根据用户请求和上下文，判断是否需要调用工具、调用哪个工具，并从自然语言中精确提取出符合工具 Schema 要求的参数。
• 编排与执行：支持工具的顺序、并行或条件执行。高级框架能处理工具间的依赖关系，例如，必须先调用“查询用户订单”工具，才能使用“申请售后”工具。
• 错误处理与降级：具备完善的错误处理机制，如网络超时重试、参数验证失败回退、主工具失败时调用备用工具等，确保任务流程的鲁棒性。

2.3 Memory 记忆系统

记忆系统赋予 Agent 持续性和个性化能力，使其能够进行有上下文的、连贯的多轮交互。

• 分层记忆架构：
  • 短期记忆/工作记忆：存储在当前对话上下文窗口内，用于保持对话连贯性，通常受模型 Token 限制。
  • 长期记忆：持久化到外部存储（向量数据库、关系型数据库、图数据库），用于存储跨会话的用户偏好、历史对话摘要、学到的知识等。
  • 外部知识记忆：通过检索增强生成（RAG）技术，在需要时从知识库、文档、API 中实时获取信息。
• 记忆的读写与压缩：系统需要智能地决定何时将重要信息从短期记忆写入长期记忆，以及如何从海量长期记忆中高效检索出与当前任务最相关的片段。常用的技术包括基于嵌入向量的相似性检索和记忆摘要生成。
• 记忆的关联与推理：高级记忆系统支持记忆条目之间的关联（如通过知识图谱），使 Agent 能进行更复杂的联想和推理。

2.4 Context 上下文管理

上下文管理负责高效、智能地组织和使用有限的模型上下文窗口，是解决“上下文溢出”问题的核心。

• 上下文窗口优化：采用策略性压缩技术，如丢弃不重要的中间 Token、对历史对话进行摘要、仅保留与当前任务高度相关的上下文片段。
• 分层与优先级：对上下文内容进行分层，例如，将系统指令、最近几条对话、关键工具调用结果置于高优先级位置，而将早期的普通对话置于可被压缩或丢弃的低优先级区域。
• 动态上下文构建：并非每次请求都携带全部历史，而是根据当前对话轮次和任务目标，动态组装一个最精简、最有效的上下文提交给模型，以节省 Token 并提升模型关注度。

2.5 MCP（Model Context Protocol）

MCP（Model Context Protocol）是一种新兴的开放协议，旨在标准化模型与外部上下文源（如数据库、文件系统、API）之间的交互。

• 协议化数据接入：MCP 定义了服务器（提供上下文数据）和客户端（如 Agent 框架）之间的标准通信方式。任何符合 MCP 的服务都可以轻松地将自己的数据暴露给 Agent 使用。
• 动态上下文注入：通过 MCP，Agent 可以在推理过程中按需、实时地从外部源获取最新、最相关的上下文信息，而无需将所有数据预先加载到有限的提示词中。例如，在编写代码时，动态获取相关文件的内容；在分析数据时，实时查询数据库。
• 提升新鲜度与准确性：解决了传统 RAG 可能存在的知识滞后问题，确保 Agent 使用的信息是最新的。
• 生态与工具集成：MCP 促进了工具和上下文源的生态建设，开发者可以为其数据源编写 MCP 服务器，即可被所有支持 MCP 的 Agent 框架无缝使用。

这些核心组件相互协作，共同支撑起现代 Agent 的复杂能力。Prompt 系统引导思考，Function Call 执行动作，Memory 系统保存经验，Context 管理优化资源，而 MCP 则打开了连接无限外部知识的大门。它们被 Harness（框架层）有机地整合在一起，使得 Model（模型层）的能力得以安全、可靠、高效地释放。

3. 相关核心概念

在理解了 Agent 的理论模型、现代架构及其核心组件后，我们还需要深入探讨几个关键的工程概念。这些概念是构建可靠、可扩展 Agent 系统的基石，它们解决了 Agent 在生产环境中运行时的执行流程、状态管理和系统设计等核心问题。

3.1 Agent Loop（Agent 执行循环）

Agent Loop 是 Agent 执行任务的核心控制流程，它定义了 Agent 如何感知环境、思考决策、执行动作并更新状态的循环过程。一个完整的 Agent Loop 通常包含以下阶段：感知（Perception）→ 思考（Reasoning）→ 行动（Action）→ 学习（Learning）。根据应用场景的不同，Agent Loop 可以分为内部循环和外部循环两种模式。

3.1.1 内部 Agent Loop（Single-Agent Loop）

内部 Agent Loop 指单个 Agent 在处理一个任务时的内部执行循环。这是最基本的 Agent 执行模式，适用于大多数独立任务场景。

• 感知阶段：Agent 接收来自用户或环境的输入，这可能包括用户查询、传感器数据、API 响应等。输入经过预处理后，被转换为 Agent 可以理解的内部表示。
• 思考阶段：Agent 的核心决策环节。模型基于当前输入、历史记忆和可用工具，进行规划、推理和决策。这可能涉及任务分解、工具选择、参数确定等复杂思维过程。先进的框架会集成 Chain-of-Thought（CoT）、Tree-of-Thought（ToT）等推理技术来提升此阶段的可靠性。
• 行动阶段：Agent 执行在思考阶段确定的动作。这通常包括：
  • 调用工具：执行一个或多个 Function Call，如查询数据库、调用 API、运行代码等。
  • 生成回复：直接向用户输出文本、图像或其他形式的内容。
• 状态更新与学习：行动完成后，Agent 根据执行结果更新内部状态（如更新记忆、修改任务计划），并可能进行简单的在线学习（如调整策略）。然后，循环回到感知阶段，等待下一轮输入或判断任务是否完成。

内部循环的设计强调自主性和连续性，目标是让单个 Agent 能独立完成一个端到端的复杂任务。

3.1.2 外部 Agent Loop（Multi-Agent Orchestration）

外部 Agent Loop 涉及多个 Agent 之间的协作与编排，用于解决单个 Agent 能力不足或需要分工协作的复杂问题。这通常由一个编排器（Orchestrator）或主控 Agent（Controller Agent）来管理。

• 任务分解与分配：编排器接收一个宏观任务（如“开发一个Web应用”），将其分解为多个子任务（前端开发、后端开发、测试部署），并分配给具有相应专长的子 Agent。
• 子 Agent 执行：每个子 Agent 运行自己的内部 Agent Loop，处理分配到的子任务。它们之间可能需要通信和共享上下文。
• 协调与同步：编排器监控所有子 Agent 的进度，处理它们之间的依赖关系（如后端 API 必须先于前端联调），并解决可能出现的冲突。
• 结果整合与最终输出：所有子任务完成后，编排器收集各子 Agent 的结果，进行整合、验证，并生成最终的输出或交付物。

外部循环体现了系统性和协作性，是现代 Agent 应用于复杂工作流（如软件开发、科研探索、业务流程自动化）的关键模式。框架如 AutoGen、CrewAI 专门为此类多 Agent 编排而设计。

3.2 Checkpoint（检查点 / 持久化）

Checkpoint（检查点）是 Agent 系统实现可靠性和长时任务支持的关键机制。它允许系统将 Agent 的完整执行状态（包括记忆、任务进度、中间结果等）持久化保存，并在需要时（如系统崩溃、主动暂停后）从中断点精确恢复。

• 状态快照：Checkpoint 捕获的是 Agent 在某一时刻的完整“快照”，包括：
  • 对话历史与上下文：当前的完整对话状态。
  • 任务执行状态：任务计划、已完成和待完成的子步骤。
  • 工具调用历史与结果：所有已执行工具的参数和返回值。
  • 内部推理状态：模型的思维链、临时决策等。
  • 记忆内容：工作记忆和相关的长期记忆索引。
• 触发时机：检查点可以在以下时机创建：
  • 定期保存：按时间间隔（如每5分钟）或执行步骤数自动保存。
  • 关键里程碑：在完成一个重要子任务后。
  • 用户主动请求：用户手动点击“保存”或“暂停”。
  • 系统异常前：在检测到可能崩溃前尝试保存最后状态。
• 恢复流程：当需要恢复时，系统从存储中加载最新的检查点，重新初始化 Agent 的所有组件（模型会话、记忆、工具状态等），并从保存点继续执行，对用户而言体验几乎无缝。
• 存储后端：检查点数据通常序列化（如 JSON、MessagePack）后存储于数据库（如 Redis、PostgreSQL）或对象存储（如 S3）中，并建立索引以便快速检索。

Checkpoint 机制使得 Agent 能够处理运行时间远超模型上下文窗口或单次会话限制的超长任务，也是实现 Agent 即服务（Agent-as-a-Service）高可用性的基础。

3.3 Agent Runtime（运行时）

Agent Runtime 是 Harness（框架层）中负责驱动单个 Agent Loop 执行的核心引擎。它是将模型、工具、记忆等组件粘合在一起，并按照既定流程一步步执行任务的“指挥中心”。

• 核心职责：
  1. 生命周期管理：初始化 Agent、运行主循环、处理暂停/恢复/终止信号。
  2. 流程调度：严格按“感知→思考→行动→更新”的步骤调用相应组件。
  3. 上下文管理：在每一步执行前后，负责组装和传递正确的上下文给模型（即管理有限的 Token 窗口）。
  4. 工具执行代理：接收模型发出的工具调用请求，定位具体工具，传入参数，执行，并将结果格式化后返回给模型。
  5. 状态推进：根据每一步的结果，更新 Agent 的内部状态机，决定下一步是继续循环、完成任务还是报错退出。
• 与 Harness 的关系：可以将 Harness 理解为 Agent 的“操作系统”，而 Runtime 则是这个操作系统中的“进程管理器”或“执行引擎”。一个 Harness 可以同时运行和管理多个独立的 Agent Runtime 实例，以服务不同用户或任务。
• 可观测性集成：Runtime 会生成详细的执行日志、性能指标（每一步的耗时）和追踪信息，这些是系统可观测性的主要数据来源，用于监控、调试和优化 Agent 性能。

简而言之，Runtime 是 Agent “活”起来并开始工作的那个瞬间所依赖的执行环境。

3.4 Agent Harness（框架/装备层）

Agent Harness 在文章 1.3 节已有概述，这里从“核心概念”角度进行补充和深化。Harness 是一整套用于构建、部署、运行和管理 Agent 的软件框架和基础设施。它不是一个单一工具，而是一个包含 Runtime、工具管理、记忆系统、安全模块、可观测性等子系统的完整平台。

• 设计哲学：Harness 的核心设计哲学是分离关注点。它将模型（智能）与实现智能所需的工程复杂性（可靠性、安全性、扩展性）解耦。开发者只需关注业务逻辑和提示词工程，而将生产级挑战交给 Harness 处理。
• 关键价值：
  • 降低开发门槛：提供高级 API 和 SDK，让开发者能像组装积木一样构建 Agent。
  • 保障生产就绪：内置了重试、熔断、降级、权限、审计等企业级特性。
  • 实现组件标准化：定义了工具、记忆、上下文等组件的标准接口，促进了生态互操作性。
  • 提供统一管控面：通过控制台或 API 对部署的 Agent 进行监控、配置更新、版本管理。
• 流行实例：LangChain、LlamaIndex 的 Agent 相关模块、Microsoft Autogen、CrewAI、以及国内外的各类商业/开源 Agent 平台，都可以视为不同形态的 Harness。

Harness 的成熟度直接决定了 Agent 技术从“演示原型”走向“核心业务系统”的进程。

Agent Loop 定义了 Agent 如何“思考”和“行动”的节拍；Checkpoint 确保了 Agent 在长跑中不会“跌倒失忆”；Runtime 是让 Agent 每一步都能踏出的“地面”；而 Harness 则为整个旅程提供了“装备、地图和后勤支持”。理解这些核心概念，有助于我们不仅在理论上，更在工程实践上，设计和构建出真正强大、可靠的智能体系统。

4. 总结

我们从 Agent 的理论起源出发，探讨了其核心构成（LLM + Planning + Memory + Tool Use），并深入剖析了将理论落地为生产系统所必须面对的工程化挑战与解决方案。

现代 Agent 架构已演进为Model + Harness的双层范式。Model 层作为智能核心，负责理解、推理与生成；Harness 层则作为基础设施，集成了 Prompt 系统、Function Call、Memory、Context 管理、MCP 等核心组件，解决了可靠性、安全性与扩展性等生产级问题。

进一步，我们探讨了构建可靠 Agent 系统所依赖的关键工程概念：Agent Loop定义了任务执行的节拍，Checkpoint保障了长时任务的可靠性，Runtime提供了具体的执行环境，而Harness则构成了支撑这一切的完整框架。

纵观其发展，Agent 技术正经历从“演示原型”到“核心业务系统”的深刻转变。它不再仅仅是更聪明的聊天机器人，而是能够自主规划、使用工具、持续学习、并在复杂环境中可靠执行的智能系统。这一转变不仅推动了软件开发范式的革新，也为各行各业的自动化与智能化开启了新的可能性。未来，随着模型能力的持续进化与工程框架的日益成熟，Agent 必将在更广泛的场景中发挥关键作用，成为人机协作的新范式。