跳转至

第三章 Agent 工程能力

本章概览

本章覆盖让 Agent 从"能跑"到"好用"的工程化技术: 记忆系统、RAG 检索增强、上下文工程、智能体通信协议、主流框架图谱、性能评估, 以及封装 Agent 运行时逻辑的 Harness 外壳。这些能力是 Agent 走向生产的关键。

小节目录

3.1 记忆系统

定义

记忆系统让 Agent 跨轮次与跨会话保留信息, 突破上下文窗口的物理限制, 实现长期一致性。它使得 Agent 能够记住用户偏好、过往交互与已学技能, 而非每次对话都从零开始。记忆系统是 Agent 从"一次性问答工具"走向"长期协作伙伴"的基础设施。

原理

记忆按时间维度分为短期记忆 (short-term memory) 与长期记忆 (long-term memory): 短期记忆指上下文窗口内的对话历史, 随会话结束而消失; 长期记忆则存储在外部系统 (如向量库、键值存储、关系数据库), 跨会话持久化。借鉴认知科学, 长期记忆又细分为三类 — 语义记忆 (semantic memory, 事实知识, 如"巴黎是法国首都")、情景记忆 (episodic memory, 具体经历, 如"用户上周问过部署问题")、程序记忆 (procedural memory, 技能与规则, 如"调用某 API 需先鉴权")。

记忆管理包含四个核心操作: 写入 (encoding) 决定哪些信息值得持久化; 检索 (retrieval) 根据当前上下文召回相关记忆; 遗忘 (forgetting) 通过衰减或淘汰机制防止记忆膨胀; 压缩 (summarization) 将冗长历史归纳为摘要以节省空间。四者协同构成完整的记忆生命周期。

Agent 框架集成记忆系统遵循通用四步模式: 推理前加载 (pre-inference load) 根据当前 user-query 从长期记忆检索相关信息; 上下文注入 (context injection) 将检索结果注入短期记忆辅助模型推理; 记忆更新 (memory update) 推理完成后将本次短期记忆写入长期记忆; 信息处理 (information processing) 长期记忆内部结合 LLM 与向量化模型完成信息提取与检索。短期记忆与长期记忆形成双向交互 — 长期记忆从短期记忆中提取"事实/偏好/经验" (Record), 又被检索注入短期记忆辅助推理 (Retrieve), 两者循环更新。

长期记忆作为独立组件, 涉及六类核心组件协同: LLM 大模型负责记忆的语义理解、抽取、决策与生成; Embedder 向量化将文本转为语义向量; VectorStore 向量数据库持久化存储记忆向量与元数据; GraphStore 图数据库存储实体-关系知识图谱, 支持复杂关系推理; Reranker 重排序器对初步检索结果按语义相关性重排; SQLite 等关系库记录所有记忆操作的审计日志, 支持版本回溯。Record 流程为 "LLM 事实提取 → 信息向量化 → 向量存储 → (复杂关系存储到图) → 操作日志"; Retrieve 流程为 "query 向量化 → 向量库语义检索 → 图库关系补充 → Reranker/LLM 精排 → 结果返回"。实践中长期记忆常以第三方组件形式集成, 代表方案有 Mem0 (事实标准级开源框架)、Zep、Memos、ReMe (AgentScope 官方实现), Agent 框架通过 API 接入。

关键点

长期记忆常基于向量检索 (vector retrieval) 实现, 通过 embedding 相似度召回相关条目; 遗忘机制是工程必备, 否则记忆库会无限膨胀导致检索质量下降。压缩 (摘要) 是长程任务的必备手段, 把多轮交互压缩为关键事实后再写回记忆。需要强调: Memory ≠ RAG — Memory 记录的是 Agent 自身经历与用户交互, RAG 检索的是外部知识库; 前者是"主观记忆", 后者是"客观资料"。

长期记忆系统在工程上面临三类核心挑战: 准确性挑战包含记忆建模 (需完善的用户画像模型)、记忆管理 (基于画像提取有效信息并设计更新机制)、检索相关性 (依赖向量化与重排能力); 安全与隐私挑战需解决数据加密与访问控制、防恶意数据注入、透明数据管理与用户掌控权; 多模态记忆挑战则是文本/视觉/语音仍被孤立处理, 构建统一"多模态记忆空间"与跨模态毫秒级响应仍是未解难题。行业趋势上, 记忆即服务 (Memory-as-a-Service, MaaS) 正成为 Agent 基础设施, 类似"数据库"之于传统软件; 精细化记忆管理借鉴人脑机制构建分层动态架构 (向量化检索类比海马体, LLM 提纯类比大脑皮层, 强化学习优化记忆管理); 多模态记忆系统则随多模态大模型兴起向跨模态方向发展。

应用·对比

短期记忆与长期记忆的对比:

维度 短期记忆 长期记忆
存储位置 上下文窗口 外部存储 (向量库/KV/DB)
持久性 会话内 跨会话
检索方式 直接拼接到 Prompt 向量检索/关键字检索
容量 受 token 限制 近乎无限
典型内容 当前对话历史 用户偏好/过往任务/已学技能

三类长期记忆的对比:

记忆类型 内容 存储方式 检索方式 示例
语义记忆 事实知识 向量库/知识图谱 语义相似度 "用户是 Java 开发者"
情景记忆 具体经历 时间索引向量库 时间+语义 "上周讨论过 RAG 方案"
程序记忆 技能/规则 规则库/SOP 触发条件匹配 "调用 API 前需鉴权"

长期记忆与 RAG 的对比 (技术架构相似但定位不同):

维度 长期记忆 (Memory) RAG
数据来源 Agent 自身交互沉淀 (用户偏好/历史/经验) 外部知识库 (文档/手册/资料)
写入方式 从短期记忆中实时抽取 (Record) 离线批量导入 (分块+向量化)
更新频率 实时/高频, 随会话演进 低频, 文档更新时重建
检索目标 个性化推理 (千人千面) 知识问答 (客观事实)
技术相似点 向量化存储+相似性检索+上下文注入 同左
典型产品 Mem0 / Zep / ReMe LangChain RAG / LlamaIndex

3.2 RAG 检索增强

定义

RAG (Retrieval-Augmented Generation, 检索增强生成) 通过在生成前检索外部知识, 将相关片段拼接到 Prompt 中, 缓解 LLM 知识截止 (training cutoff) 与幻觉 (hallucination) 问题。它把"参数化知识"与"外部文档"结合, 让模型基于最新或私有资料回答, 而非依赖训练时记忆。RAG 是企业 LLM 应用最普遍的落地形态。

原理

基础流程包含五个阶段: 文档分块 (chunking) 将长文档切分为可检索单元; Embedding 编码将每个 chunk 转为向量; 向量库 (vector store, 如 FAISS/Milvus/Pinecone) 存储向量与原文; 查询时用相同 encoder 编码 query 并检索 top-k 相似 chunk; 将检索结果拼接到 Prompt 后送入 LLM 生成答案。

进阶技术持续提升检索质量: Hybrid Search (混合检索) 融合关键词检索 (BM25/稀疏) 与向量检索 (稠密), 兼顾精确匹配与语义相似; Rerank (重排序) 用 cross-encoder 模型 (如 Cohere Rerank/BGE-Reranker) 对召回结果精排, 显著提升相关性; 自查询 (self-query) 让 LLM 将自然语言转为结构化查询, 支持元数据过滤; GraphRAG (微软提出) 构建知识图谱增强检索, 适合实体关系密集场景, 能回答跨文档的全局性问题。

Chunk 策略直接影响检索质量: 固定大小 (fixed-size) 切分简单但可能切断语义; 语义分块 (semantic chunking) 按主题边界切分更合理; 层级分块 (hierarchical chunking) 同时保留小粒度与大上下文, 支持父子检索。三者各有取舍, 需结合文档结构与查询模式选择。

关键点

Chunk 大小是检索精度的核心权衡: 小 chunk 命中精确但缺乏上下文, 大 chunk 上下文完整但稀释关键信息, 工程上常选 256-512 token 并配合重叠窗口。Rerank 是性价比最高的提升手段, 在召回后加一道 rerank 往往能将准确率提升 10-20%。GraphRAG 适合实体关系密集的领域 (如金融/法律/医疗), 但构建成本高, 通用场景未必划算。

应用·对比

三种 RAG 方案的对比:

方案 实现复杂度 检索质量 适用场景
朴素 RAG 低 中 通用问答、小规模文档
Hybrid Search + Rerank 中 高 生产级 RAG、企业知识库
GraphRAG 高 高 (关系密集场景) 金融/法律/医疗、跨文档推理

3.3 上下文工程

定义

上下文工程 (Context Engineering) 是系统化管理 Agent 上下文窗口的技术, 决定哪些信息进入、何时压缩、如何分配 token 预算。它不只是"塞入更多信息", 而是有限窗口下的资源调度问题。随着 Agent 任务变长、工具变多、记忆变厚, 上下文工程成为区分"能用的 Agent"与"好用的 Agent"的关键。

原理

上下文工程存在狭义与广义之分: 狭义上下文工程特指对短期记忆 (会话历史) 的运行时处理, 主要解决上下文窗口限制与 token 成本问题; 广义上下文工程则涵盖更广的上下文优化策略, 包括非运行态的模型选择、Prompt 优化、知识库构建、工具集构建等推理前优化手段。本节聚焦狭义上下文工程, 即针对短期记忆的运行时处理策略。

上下文窗口是稀缺资源, 即使长上下文模型 (1M+) 也存在 lost in the middle 现象 — 中间位置的信息容易被忽略。常见管理手段有三类: 上下文压缩 (compression) 用 LLM 对历史对话生成摘要, 替换原始消息以节省 token; 滑动窗口 (sliding window) 只保留最近 N 轮对话, 早期信息直接丢弃; 摘要链 (summary chain) 采用滚动摘要策略, 每隔若干轮将旧消息压缩为摘要并累积, 兼顾近期细节与远期梗概。

针对短期记忆的运行时处理, 工程上总结出三种核心策略, 与上述手段互补使用。上下文缩减 (Context Reduction) 通过减少信息量降低 token 消耗, 具体分为保留预览 (对大块内容只保留前 N 字符或关键片段) 与总结摘要 (LLM 摘要整段内容), 两者都会丢信息但能有效省 token。上下文卸载 (Context Offloading) 解决被缩减内容的可恢复性 — 原始完整内容卸载到外部存储 (文件系统/数据库), 消息中只保留最小引用 (文件路径/UUID), 需要时通过引用重新加载, 适用于网页搜索结果、超长工具输出、临时计划等占 token 较多的内容。上下文隔离 (Context Isolation) 借鉴多智能体架构, 将上下文拆分到不同子智能体 (类似单体拆分为微服务), 主智能体编写任务指令发送给子智能体, 子智能体上下文仅由该指令组成, 完成后只返回结果, 主智能体不关心执行细节, 适用于任务指令清晰简短、只需最终输出的场景 (如代码库搜索特定片段)。

token 预算分配是上下文工程的核心决策: 系统提示 (system prompt)、记忆召回 (memory)、RAG 检索结果、当前对话、工具描述各自占用多少 token 需动态平衡。例如简单问答可把预算大头给当前对话, 复杂推理任务则需预留更多给 RAG 与记忆。

与 Memory、RAG 的关系: Memory 和 RAG 都是上下文工程的"信息源", 上下文工程决定如何把它们塞进有限窗口。Memory 提供历史交互, RAG 提供外部知识, 上下文工程则是"调度层", 决定何时召回、保留多少、如何压缩。三者协同构成 Agent 的信息供给体系。

关键点

长上下文模型 (1M+) 不等于无需上下文工程 — lost in the middle 仍然存在, 且长上下文成本高、推理慢。压缩要保留关键事实而非全部细节, 摘要质量直接决定后续表现。token 预算分配需动态调整: 不同任务对 system/RAG/memory 的需求比例不同, 固定分配会浪费或不足。三种核心策略的选择需综合考虑: 时间远近 (近期消息优先保留, 历史消息优先缩减或卸载)、数据类型 (用户输入/模型回复/工具结果重要性不同)、信息可恢复性 (需完整信息用卸载, 可接受丢失用缩减)。

应用·对比

三种上下文管理方式的对比:

方式 实现难度 信息保留 适用场景
滑动窗口 低 仅近期 短会话、实时聊天
摘要链 中 滚动摘要 长程任务、跨轮一致性
上下文压缩 高 关键事实 复杂推理、长文档分析

三种核心策略 (缩减/卸载/隔离) 的对比:

策略 核心机制 信息是否可恢复 适用场景
上下文缩减 保留预览/总结摘要 否 (信息丢失) 可接受信息丢失的常规对话
上下文卸载 原始内容外存, 保留引用 是 (按需重载) 网页搜索结果、超长工具输出
上下文隔离 拆分到子智能体 子智能体内部隔离 指令清晰只需最终输出的子任务

3.4 智能体通信协议

定义

智能体通信协议 (Agent Communication Protocol) 标准化 Agent 与工具、Agent 与 Agent 之间的交互接口, 解决"M×N 集成"变为"M+N 接入"的问题。在协议出现前, 每个工具需为每个 Agent 框架单独适配, 协议统一后, 工具实现一次即可被所有兼容 Agent 调用。这是 Agent 生态走向规模化的基础设施。

原理

当前主流协议有四种, 定位各有侧重。MCP (Model Context Protocol, Anthropic 2024) 标准化 Agent 与外部工具/数据源的连接, 被类比为"AI 的 USB-C" — 它定义了工具描述、调用、结果回填的统一格式, 让任意 LLM 都能接入任意 MCP server。A2A (Agent-to-Agent, Google 提出) 关注 Agent 间的通信, 让不同框架构建的 Agent 能互相发现、协商、协作。ANP (Agent Network Protocol) 面向多 Agent 互联的更广网络, 设想跨组织、跨平台的 Agent 互联网。Agent Skills 则是另一种思路: 按需加载的工具包, 与 MCP 互补 — MCP 暴露单个工具, Skills 渐进式披露整个工具仓库, 通过检索按需加载而非全塞 Prompt。

四者并非完全竞争: MCP 解决工具接入, A2A/ANP 解决 Agent 互联, Skills 解决工具过载。实际系统可能同时使用多种协议, 例如用 MCP 暴露基础工具, 用 Skills 管理海量工具仓库, 用 A2A 与其他 Agent 协作。

关键点

MCP 是当前最主流的工具协议, 已被 Claude/Cursor/Cline 等广泛采用, 生态最成熟。A2A/ANP 尚在早期, 标准与实现都在演进。Skills 解决"工具过多导致 Prompt 膨胀"问题, 核心思路是检索 + 按需加载, 而非把所有工具描述塞进上下文。选型时优先考虑 MCP, 多 Agent 协作再考虑 A2A。

应用·对比

四种协议的对比:

协议 定位 解决域 成熟度
MCP Agent 与工具 工具接入标准化 高 (生态成熟)
A2A Agent 与 Agent 跨框架 Agent 通信 中 (标准演进中)
ANP Agent 网络 跨组织 Agent 互联 低 (早期探索)
Agent Skills 工具仓库管理 工具过载与按需加载 中 (与 MCP 互补)

3.5 主流框架图谱

定义

Agent 框架 (Agent Framework) 提供 Agent Loop、工具调度、记忆管理等抽象, 降低 Agent 开发门槛, 让开发者专注业务逻辑而非底层循环。框架本质上是对 Agent 工程能力的封装, 不同框架在编排模型、多 Agent 支持、易用性上各有取舍。

原理

主流框架按编排模型可分为三类: 链式 (chain)、图式 (graph)、对话式 (conversation)。LangChain 是最早最全的框架, 以链式抽象为核心, 模块丰富但被批评"过度抽象", 适合快速原型。LangGraph 是 LangChain 团队出品的图式编排框架, 用状态机与节点边表达复杂流程, 适合需要条件分支、循环、人工介入的生产级 Agent。AutoGen (Microsoft) 是多智能体对话框架, 通过 Agent 间消息传递实现协作, 适合研究型多 Agent 场景。CrewAI 以角色化多 Agent 协作为特色, API 友好、上手快, 适合任务分工明确的场景。AgentScope (阿里) 是国产多 Agent 框架, 中文文档完善, 适合国内场景。Dify 则是低代码 Agent 平台, 偏 Workflow 路线, 适合非技术用户快速搭建应用。

六大框架并非完全替代关系: LangChain/LangGraph 偏开发者, Dify 偏业务人员, AutoGen/CrewAI/AgentScope 偏多 Agent 研究。选型需结合团队技术栈、任务复杂度、是否需要多 Agent 协作。

关键点

框架本质是 Harness (见 3.7) 的一种实现 — 它们封装了 Agent Loop、工具调度、上下文管理等运行时逻辑, 让上层只关心业务。选型看三件事: 编排复杂度 (链/图/对话)、生态 (插件/社区/文档)、语言 (Python/JS/Java)。自研框架是"造轮子"路径但可控性最高, 适合有特殊需求或想深度定制 Harness 的团队。

应用·对比

六大框架的对比:

框架 编排模型 多 Agent 支持 学习曲线 适用场景
LangChain 链式 弱 中 快速原型、单 Agent
LangGraph 图式 中 陡 复杂状态机、生产级 Agent
AutoGen 对话式 强 中 多 Agent 研究、辩论
CrewAI 角色链 强 平 任务分工多 Agent
AgentScope 图式 强 中 国产多 Agent 场景
Dify 工作流 中 平 低代码、业务人员

3.6 智能体性能评估

定义

智能体性能评估 (Agent Evaluation) 衡量 Agent 在任务上的成功率、效率、鲁棒性, 是 Agent 走向生产的必备环节。未经评估的 Agent 难以判断改进方向, 也无法在版本迭代中保证质量。评估 Agent 比评估 LLM 更难, 因为 Agent 的输出是轨迹 (trajectory) 而非单次响应。

原理

核心指标分为四类: 成功率 (task success rate) 衡量任务是否完成, 是最根本的指标; 步数 (steps) 衡量效率, 步数过多可能意味着规划能力不足; token 消耗 (cost) 衡量成本, 直接关系商业化可行性; 时延 (latency) 衡量响应速度, 影响用户体验。四者常需权衡, 例如提高成功率可能增加步数与 token。

基准测试 (benchmark) 提供标准化评估场景: AgentBench 是多任务综合基准, 覆盖购物/操作系统/数据库等多种环境; GAIA 是通用助手基准, 测试真实世界多模态多步推理; SWE-bench 是软件工程基准, 要求 Agent 修复真实 GitHub issue; τ-bench 是工具调用基准, 测试 Agent 在模拟客服场景下的多轮工具使用。四个基准侧重点不同, 选型需匹配 Agent 的目标场景。

评估方法分三类: 轨迹评估 (trajectory evaluation) 评估中间步骤是否正确, 能定位失败点但成本高; 端到端评估 (end-to-end evaluation) 只看最终结果, 简单但易遗漏中间错误; LLM-as-Judge 用强模型 (如 GPT-4) 评判弱模型轨迹, 可扩展但有偏见与一致性风险。三者常组合使用, 关键任务用轨迹评估, 大规模评测用 LLM-as-Judge。

关键点

端到端评估简单但易遗漏中间错误 — Agent 可能"瞎猫碰上死耗子"得到正确结果但过程错误。轨迹评估能定位失败点但成本高, 适合调试与关键任务。LLM-as-Judge 有偏见 (偏好长回答/自家模型) 但可扩展, 是大规模评测的折中方案。生产 Agent 应建立持续评估流水线, 每次迭代都跑基准。

应用·对比

四大基准测试的对比:

基准 任务类型 难度 适用 Agent 类型
AgentBench 多任务综合 中 通用 Agent
GAIA 真实世界多步推理 高 通用助手
SWE-bench 软件工程 (修 bug) 高 Coding Agent
τ-bench 工具调用 (客服场景) 中 工具型 Agent

3.7 Agent Harness

定义

Harness (运行时外壳) 是 Agent 的运行时外壳, 封装 LLM 调用循环、工具调度、状态维护, 让上层只关心业务逻辑; 它是 Agent 的"操作系统"层, 把分散的工程能力收敛为可复用的运行时。没有 harness, 开发者每次构建 Agent 都要重新实现工具循环、错误处理、上下文压缩等基础设施; 有了 harness, 业务逻辑与运行时逻辑解耦, Agent 的可靠性、可观测性、可扩展性都有了保障。Harness 一词源自"马具/挽具", 意为"驾驭 LLM 的工具集"。

原理

Harness 承担六项核心职责, 共同构成 Agent 的运行时骨架。

第一, 工具循环 (Agent Loop): 这是 harness 的心脏, 执行"LLM 输出 → 解析工具调用 → 执行工具 → 结果回填上下文 → 再次调用 LLM"的循环, 直到任务完成或达到终止条件。循环看似简单, 但要处理流式输出、并行工具调用、工具调用嵌套等复杂情况, 是 Agent 区别于单次 LLM 调用的本质特征。一个健壮的 Agent Loop 还需考虑循环终止条件 (最大步数/超时/明确完成信号)、循环间状态持久化 (用于断点续跑)、循环内异常处理 (单步失败是否终止整体)。

第二, 上下文管理: harness 负责消息历史维护、上下文压缩、token 预算分配, 与 3.3 上下文工程直接对应。具体包括: 维护完整的消息序列 (system/user/assistant/tool 角色)、在窗口接近上限时触发压缩或摘要、为不同信息源 (system/memory/RAG/当前对话) 分配 token 预算。好的上下文管理让 Agent 能跑长程任务而不"失忆", 差的上下文管理会导致关键信息被挤出窗口、Agent 行为漂移。

第三, 错误恢复与重试: 工具调用会失败, LLM 输出会格式异常, 网络会超时, harness 必须有兜底策略。常见策略包括: 重试 N 次 (带退避)、降级到备选工具、把错误信息回填给 LLM 让其换思路。错误恢复的好坏直接决定 Agent 在生产环境的鲁棒性 — 实验室里跑通的 Agent, 到了生产环境遇到网络抖动、工具限流、格式异常, 没 harness 兜底很快就会崩。

第四, 多步编排: harness 提供单步、链式、图式执行的统一抽象, 决定 Agent 如何拆解与推进任务。单步是"一问一答", 链式是"按顺序执行多步", 图式是"带分支与循环的复杂流程"。LangGraph 的状态机、AutoGen 的对话轮次、CrewAI 的角色链, 本质都是 harness 层的编排抽象。编排模型的选择取决于任务复杂度: 简单任务用单步, 线性任务用链式, 复杂任务用图式。

第五, 权限与沙箱: harness 负责工具调用的鉴权、文件/网络访问边界, 防止 Agent 越权。例如 Coding Agent 必须限制可写目录 (避免误删用户文件)、限制网络访问 (避免数据外泄)、限制可执行命令 (避免 rm -rf)。沙箱是 Agent 走向生产的安全护栏, 没有沙箱的 Agent 在真实环境中是危险的 — 一个幻觉的工具调用可能删除重要数据或泄露敏感信息。

第六, 可观测性: harness 提供 trace (调用链)、metrics (指标)、hook (钩子) 三类观测能力, 用于评估与调试。trace 记录每一步的输入输出, 是定位失败的基础; metrics 统计 token 消耗、步数、时延、成功率, 是优化的依据; hook 允许在循环各阶段注入自定义逻辑 (如日志/审计/人工介入)。生产 Agent 没有可观测性等于盲飞 — 出了问题无法定位, 性能瓶颈无从发现。

Harness vs Framework 的关系: LangGraph、AutoGen、CrewAI 等框架本质是 harness 的一种实现, 它们各自实现了上述六项职责, 只是抽象方式与侧重点不同。自研 harness 是"造轮子"路径, 成本高但可控性最强, 适合有特殊需求或想把运行时逻辑完全掌握的团队。实际选型常是"基于框架定制" — 用框架的 harness 作底座, 在其上扩展业务专属的错误恢复、权限、可观测逻辑。

典型案例: Cursor、Claude Code、OpenAI Codex、Aider 等 Coding Agent 的核心就是精心设计的 harness。这些产品表面上差异在模型与 UI, 真正的工程壁垒在 harness — 文件读写、终端执行、diff 应用的循环如何设计, 上下文如何压缩以容纳大型代码库, 工具失败如何恢复, 用户权限如何管控。一个 Coding Agent 的好坏, 80% 取决于 harness 设计, 20% 才是模型本身。

与 MCP/Agent Skills 的协同: harness 负责调度 (决定何时调用什么工具), MCP/Skills 负责工具暴露与按需加载 (提供工具仓库)。harness 是"调度器", Skills 是"渐进式披露的工具仓库" — 当工具数量超过 Prompt 容纳上限时, harness 通过检索 Skills 按需加载相关工具描述, 而非把所有工具全塞 Prompt。这种分工让 Agent 能扩展到成百上千工具而不崩溃, 是 Agent 走向规模化工具使用的关键架构。

关键点

Harness 是 Agent 区别于"调用 LLM API"的关键层 — 调用 API 是一次性请求, harness 是持续运行的循环系统。好的 harness 让 Agent 可靠 (错误恢复)、可观测 (trace/metrics/hook)、可扩展 (动态工具加载)。自研 harness 需重点投入错误恢复与可观测性, 这两块决定了 Agent 在生产环境的存活能力。框架提供的 harness 是起点而非终点, 真正生产级的 Agent 往往需要在框架之上定制大量 harness 逻辑。

应用·对比

三款 Coding Agent 的 harness 设计对比:

维度 Cursor Claude Code Aider
工具循环 Agent Loop + Tab 补全双模式 单一 Agent Loop, 强调长程任务 Git-native Loop, 每步可回滚
上下文管理 代码库索引 (codebase indexing) + 检索 自动压缩 + 大上下文窗口 Repo map + 文件树摘要
权限沙箱 IDE 内运行, 文件读写受限 终端运行, 显式权限确认 Git 隔离, 改动可 git revert
可观测性 UI 内 trace 展示 终端日志 + hook Git commit 历史即 trace
定位 IDE 集成, 增强编码 命令行通用 Agent Git 友好的编码助手

延伸阅读