Agent Harness 横纵分析报告
作者: 丁致宇 NeverGpDzy | 研究时间：2026-04-24
所属领域：AI Agent 工程化 | 研究对象类型：技术范式 / 工程架构
一、一句话定义
Agent Harness 不是一个新 模型，也不只是把 LLM 包一层工具调用接口。它是围绕模型搭起来的一整套执行外骨骼：计划、状态、记忆、文件系统、工具、权限、子任务、评估、回滚、沙箱、人与模型之间的交互规则，都被放进这套外骨骼里。
LangChain 在 2026 年 3 月那篇文章里把话说得很直：今天最好的 Agent，不只是模型更强，而是模型外面的 harness 更成熟。模型提供智能，harness 决定这种智能能不能稳定地落到真实任务里。
这句话看起来像工程细节。
但它其实是 2026 年 Agent 赛道最重要的一次视角切换。
过去大家问的是，哪个模型更聪明。现在越来越多真正做应用的人开始问，聪明的模型到底被放进了什么样的执行系统里。
这个问题一旦问出来，Agent 的竞争图谱就变了。
二、纵向分析：从「模型会想」到「系统会做」
1. 早期的 Agent，其实是一段提示词协议
要理解 harness，不能从 2026 年的 LangChain 文章开始。
得往前退一点。
2022 年前后，大语言模型最让人兴奋的能力，不是它能接 API，也不是它能管理文件系统，而是它开始能把推理过程写出来。Chain-of-Thought prompting 让模型在答案之前 先生成中间推理步骤，ReAct 进一步把推理和行动放到同一个循环里：模型先想一步，再决定调用什么工具，再观察结果，再继续想。
ReAct 这条线非常关键。
因为它把 Agent 的最小形态讲清楚了。一个 Agent 不只是回答问题，它应该能在环境里行动。那时候的环境可能只是搜索引擎、维基百科、计算器，或者一个简单的任务环境。但动作一旦出现，Agent 就不再是纯文本生成器了。
它开始需要一个外部循环。
这个外部循环最早很朴素。提示词里规定几种格式，Thought、Action、Observation。模型按格式输出，外部程序解析出 Action，调用工具，把结果塞回上下文，再让模型继续。今天看这套东西很原始，但它已经埋下了 harness 的种子。
模型不是自己在跑。
有一段外部程序在决定什么时候把工具结果送回去，什么时候停，什么时候认为任务完成，什么时候让模型重试。
Toolformer 也在同一时期回答了另一个问题：模型能不能自己学会什么时候调用工具。它的重点在模型能力，但对工程系统的启发很直接。只要模型开始依赖外部工具，工具调用就不再是附属功能，而会变成模型完成复杂任务的基础设施。
所以 2022 年到 2023 年初，Agent 的核心想象是这样的：模型负责推理，外部工具负责补足模型做不了的事。
这时的 harness 还没有名字。
它只是那段把模型、工具、上下文粘起来的胶水。
2. AutoGPT 时刻，把 Agent 的问题暴露得非常彻底
2023 年，AutoGPT 这类项目把 Agent 推到了大众视野里。
当时很多人第一次看到模型可以自己拆任务、调用搜索、写文件、继续迭代，第一反应就是「这东西是不是要自己干活了」。那段时间的 Agent 叙事非常热，甚至有点过热。大家开始幻想一个目标丢进去，模型自己把整个项目做完。
但很快，问题也暴露出来。
模型会迷路。
它会陷入循环，会忘记前面的约束，会把工具用错，会把一个简单任务拆成一堆没有必要的步骤。它看起来一直在忙，但最后产物经常很虚。
这件事对 Agent 赛道的教育意义很大。
它告诉大家，只让模型自己「想下一步」是不够的。一个真正可用的 Agent 系统，需要任务状态，需要计划结构，需要检查点，需要工具权限，需要失败恢复，需要可观察性。否则你看到的是一台很努力的机器，但它没有方向盘、刹车和仪表盘。
这也是 LangChain 这类框架在早期迅速流行的原因。LangChain 诞生于 2022 年下半年，最开始的价值很直接：把 LLM、Prompt、工具、链式调用、检索这些东西封装起来，让开发者能更快搭应用。它不是一开始就叫 harness，但它解决的正是 harness 的早期问题。
怎么把模型接到工具上。
怎么把多步调用组织起来。
怎么把上下文、检索和输出串成流程。
只是 2023 年的行业还没有完全意识到，真正难的不是把这些能力接起来，而是让它们长期稳定地工作。
3. 2024 年，大家从「Agent 魔法」退回到「Workflow 工程」
2024 年是一个很有意思的转折点。
前一年，市场喜欢讲 autonomous agent。到 2024 年，越来越多开发者开始承认，完全放飞的 Agent 并不好用，能落地的往往是更可控的 workflow。
Anthropic 后来在《Building effective agents》里也用了类似区分：workflow 是通过预定义代码路径编排模型和工具，agent 则让模型动态决定流程。这个区分很重要。它不是在否定 Agent，而是在提醒大家，模型自由度不是越高越好。
LangGraph 正是在这个背景下变得重要。
LangGraph 的定位不是再给开发者一个更花哨的 prompt 模板，而是给 Agent 应用一个可控制的图运行时。状态可以保存，流程可以分支，节点可以重试，人可以插入，执行可以持久化。你可以把模型放在图里的某些节点，让它做判断，但整个系统不是一团自由漂浮的文本。
这就是 harness 开始从「胶水代码」变成「运行时」的过程。
同一时期，Microsoft AutoGen 把多 Agent 对话和协作推到台前，Semantic Kernel 在企业应用里强调 plugin、planner、agent framework，CrewAI 把 agents、tasks、crews、flows 包装成更容易理解的工作自动化模型，LlamaIndex 则从数据和检索出发，把 Agent 放到知识工作和 RAG 场景里。
这些路线看起来不同。
但它们都在回答同一个问题：一个 LLM 如果要长期做事，它外面到底需要多少工程结构。
答案越来越清楚。
需要很多。
4. MCP 之后，工具层开始标准化
2024 年 11 月，Anthropic 发布 Model Context Protocol。MCP 的说法很简单，它是一个开放标准，用来连接 AI assistants 和数据源、工具系统。
但它背后的变化不简单。
在 MCP 之前，每个 Agent 框架都可以有自己的工具协议。你给 LangChain 写一套 tool，给 Claude 写一套 tool，给 Cursor 或本地自动化系统再写一套。短期能跑，长期很散。工具一多，集成成本就会变成真正的瓶颈。
MCP 把这件事往标准化方向推了一步。
这对 harness 很关键。因为 harness 的价值，不只在于调模型，还在于管理模型能触碰的世界。文件系统、数据库、浏览器、GitHub、Slack、内部知识库、云服务，它们都是 Agent 的手脚。
如果工具层没有标准，harness 就会被集成成本拖住。
如果工具层开始标准化，harness 的竞争焦点就会往上移：谁更会管理状态，谁更会规划任务，谁更会保护权限，谁更会把长期记忆做成可用资产。
这就是 MCP 这一类协议的意义。它不是直接替代 harness，而是在给 harness 铺路。
5. 编程 Agent 让 harness 的价值第一次变得特别显眼
真正让 harness 这个词变得有重量的，是编程 Agent。
原因也很简单。写代码是最适合暴露 Agent 系统能力的场景。
一个编程 Agent 不能只会聊天。它要读文件，要搜索代码，要理解 repo 结构，要修改多个文件，要运行测试，要看错误日志，要回滚坏改动，要处理用户临时插进来的新要求，还要知道哪些命令危险，哪些文件不能乱动。
这时模型当然重要。
但模型外面的系统更重要。
Claude Code、OpenAI Codex、Cursor、OpenHands、Devin 这一类产品的差异，很多时候并不只在模型。更关键的是它们的 harness。有没有文件树视图，有没有 shell，有没有 patch 机制，有没有任务计划，有没有权限确认，有没有持久记忆，有没有子任务，有没有能把上下文压缩后继续推进的机制。
LangChain 那篇《The Anatomy of an Agent Harness》就是在这个背景下写出来的。文章里最有冲击力的案例，是他们在同一个模型不变的情况下，通过 harness engineering 把编程 Agent 在 Terminal Bench 2.0 的排名从 Top 30 提到 Top 5。这个结果不能过度神化，因为 benchmark 只是一个切面，但它说明了一个非常朴素的事实：Agent 能力不全在模型里。
能力也在外壳里。
LangChain 文章把 harness 拆成了几个核心部件：planning、filesystem、subagents、stateful middleware、context engineering、tool and permission layer、evaluation loop。这里面每一项看起来都不神秘，但组合起来就会改变 Agent 的工作方式。
Planning 解决的是模型短期冲动的问题。模型很容易被眼前一步吸引，计划工具让它能把任务拆开、标记进度、回看下一步。
Filesystem 解决的是上下文窗口的问题。模型不可能把所有东西永远塞在 prompt 里，文件系统变成外部工作记忆。中间结果、草稿、长文档、代码片段，都可以被放到上下文之外，需要时再读回来。
Subagents 解决的是上下文污染和角色分工的问题。一个主 Agent 不必把所有细节塞进自己的上下文，可以把局部任务交给专门的子 Agent，拿回压缩后的结果。
Stateful middleware 解决的是长期行为模式的问题。模型每一步看到什么、用什么工具、继承什么记忆、遵守什么策略，不应该全靠一段静态 system prompt。中间层可以动态注入上下文，也可以拦截危险动作。
这几件事合在一起，Agent 就不再是一个裸模型循环。
它成了一个小型操作系统。
6. 2026 年，harness 从工程技巧变成战略资产
到 2026 年，harness 这个词开始被更明确地摆到台前。
LangChain 这篇文章很像一次宣言：模型很重要，但不要再只盯着模型。你的 Agent 表现，可能被 harness 决定了一大截。
OpenAI 也在类似方向上推进。Agents SDK 把 agent、handoff、guardrail、session、tool 这些东西产品化，Responses API 把工具调用、远程 MCP、计算机使用、代码解释器、文件搜索等能力放进统一接口里。它不是纯开源 harness，而是模型供应商原生 harness。
Anthropic 的路线也很明显。Claude Code 和 Claude Agent SDK 把 coding agent 的实践沉淀成 SDK，MCP 则把工具接入标准化。它的优势在于产品体验很强，弱点也同样明显：越好用，越容易让关键工作流沉到供应商自己的生态里。
LangChain 的位置有点不同。
它要做的是 model-agnostic harness。也就是，模型可以换，底层工作流、状态、记忆、工具和评估尽量留在开发者手里。LangChain 后来写《Your Harness, Your Memory》，核心担心也在这里：如果 Agent 的长期记忆和执行习惯都被闭源产品拿走，用户和企业真正沉淀下来的不是自己的资产，而是平台的资产。
这就把 harness 从工程 问题推到了战略问题。
你用谁的 harness，某种程度上就是把你的工作流、上下文、记忆和控制权交给谁。
三、横向分析：当前 Agent Harness 竞争图谱
1. LangChain / LangGraph / Deep Agents：开放 harness 的代表路线
LangChain 今天的位置，不能再只用「LLM 应用框架」来理解。
它更像是在做 Agent 工程栈的三层结构。LangChain 提供基础抽象和集成，LangGraph 提供可控的图运行时，LangSmith 提供 tracing、evaluation 和 observability。Deep Agents 则把 coding agent 里被验证过的一些 harness 模式抽出来，做成可以复用的模式库。
这条路线的优点很清楚。
第一，它给开发者控制权。你可以选 OpenAI、Anthropic、Google、开源模型，可以自己定义工具，可以自己决定记忆在哪里保存。
第二，它重视 state。Agent 系统最难的不是让模型回答一句话，而是让它在多轮、多工具、多失败路径里保持状态一致。LangGraph 的核心价值就在这里。
第三，它适合做复杂业务 Agent。很多企业场景不会允许一个黑盒 Agent 随便动内部系统。它们需要人审、权限、日志、回放、版本控制、评估。LangChain 这一套更像工程团队能拿来改的骨架。
但它也有短板。
开放和可控通常会带来复杂度。开发者需要理解图、状态、节点、边、memory、checkpoint、tool schema、middleware、tracing。对只想快速做一个助理的人来说，这会显得重。
这就是 LangChain 的生态位：它不是最省心的闭源 Agent 产品，而是给想掌控 harness 的团队提供工具箱。
2. OpenAI Agents SDK / Responses API：模型供应商原生 harness
OpenAI 的 Agents SDK 走的是另一条路。
它把 Agent 开发里常见的元素直接做成 SDK 概念：Agent、Tool、Handoff、Guardrail、Session、Tracing。Responses API 又把模型输出和工具调用放进更统一的接口里，支持文件搜索、代码解释器、计算机使用、远程 MCP 等能力。
这条路线的优势是顺滑。
模型、工具、运行时、评估、日志都在同一个供应商体系里，很多地方不需要开发者自己拼。尤其是当模型本身具备更强的工具调用、结构化输出和多模态能力时，原生 harness 很容易吃到第一手红利。
它适合两类团队。
一类是已经深度使用 OpenAI 模型和 API 的团队。对他们来说，用 Agents SDK 能减少很多接线工作。
另一类是希望快速验证 Agent 产品的人。相比自己搭 LangGraph、状态存储、权限系统，OpenAI 的原生方案更快。
但它的风险也很明显。
如果你的 Agent 最重要的资产是用户工作流、长期记忆、工具调用历史和策 略偏好，那这些东西放在哪儿就很关键。供应商原生 harness 越完整，切换成本也可能越高。短期它提升效率，长期它可能形成锁定。
我的判断是，OpenAI 这条线会在通用 Agent 和企业 API 里很强，但对那些特别重视控制权、审计、私有化和模型可替换性的团队，仍然需要开放 harness 来兜底。
3. Anthropic Claude Code / Claude Agent SDK / MCP：从产品体验反推标准
Anthropic 的路线有一个很有意思的特点，它不是先做一个大而全的框架，再把产品往上套。它先把 Claude Code 这种高频使用场景打磨出来，然后把里面成熟的能力往 SDK 和协议层沉淀。
Claude Code 让很多开发者第一次强烈感受到，编程 Agent 的好坏很大程度取决于外部系统。它能读 repo、跑命令、改文件、解释 diff、处理错误，还能通过权限机制控制危险动作。这些都是 harness。
MCP 则让 Anthropic 不只是在做自己的闭源产品，而是在工具层争取一个标准位置。它不一定垄断所有 Agent harness，但它想成为 Agent 接外部世界的一种通用插座。
这条路线的优点是产品感强。
Claude Code 不是抽象论文，它天天被开发者拿来干活。真实任务会逼出真实问题：上下文太长怎么办，工具太多怎么办，用户中途改需求怎么办，测试失败怎么办，权限怎么控制。这样的产品实践反过来会让 SDK 更接近实际需求。
短板是边界。
如果你想把 Claude Code 的体验完整搬进自己的业务系统里，会遇到供应商边界。Claude Agent SDK 可以扩展一部分能力，MCP 也能把工具标准化，但核心体验和模型仍然强绑定 Anthropic 生态。
所以 Anthropic 的生态位很像高质量闭源 Agent 产品加工具标准推动者。它不一定给你最大自由度，但会不断证明什么样的 harness 真的好用。
4. Microsoft AutoGen / Semantic Kernel：企业多 Agent 和编排路线
Microsoft 这条线更像企业工程师会喜欢的路线。
AutoGen 早期用多 Agent 对话展示了 Agent 协作的可能性，后来也在往事件驱动、分布式、可扩展的 agentic application framework 演进。Semantic Kernel 则更贴近企业应用开发，强调 plugin、planner、memory、agent framework，以及和 .NET、Azure 生态的结合。
这类框架的核心问题不是「能不能做一个酷炫 demo」，而是「能不能放进企业软件架构」。
它们擅长的场景往往不是个人编程 Agent，而是流程自动化、业务系统接入、多角色协作、企业知识和权限体系。比如一个销售运营 Agent、一个内部 IT 工单 Agent、一个知识库问答和流程执行混合的 Agent，Microsoft 生态会比较顺。
缺点也来自这里。
企业级框架容易显得重。抽象层多，概念多，和云平台绑定较强。对独立开发者来说，它不如 Claude Code 那样开箱即用，也不如 CrewAI 那样容易理解。
它的生态位是稳，而不是轻。
5. CrewAI：把 Agent 协作包装成组织隐喻
CrewAI 的受欢迎，很大一部分来自它的表达方式足够直观。
agent、task、crew、flow，这些词不是技术味很重的词。普通开发者很容易理解，一个 Agent 扮演一个角色，一组 Agent 组成 crew，共同完成一套任务。
这套抽象很适合业务自动化和原型验证。
你要做一个市场调研流程，一个内容生产流程，一个销售线索处理流程，用 CrewAI 很快能搭出结构。它降低了进入门槛，也让非底层工程背景的人更容易参与 Agent 流程设计。
但它的问题是，组织隐喻有时会遮住真正的工程问题。
角色分工不等于可靠执行。多个 Agent 对话不等于系统更聪明。任务越复杂，越需要状态、权限、评估、异常恢复、上下文治理。CrewAI 如果用来做轻量流程，很舒服；如果要做高可靠生产系统，团队仍然要补很多 harness 工程。
所以 CrewAI 的位置是易用和叙事强。
它适合把 Agent 协作从 0 搭到 1，但 1 到 10 往往需要更硬的运行时和观测能力。
6. LlamaIndex Workflows / Agents：从数据和知识工作出发
LlamaIndex 的起点不是 Agent，而是数据。
它最早被广泛使用，是因为开发者 需要把私有数据接到 LLM 上。RAG、索引、检索、文档解析、知识库，这些是它的基本盘。后来 Agent 和 Workflows 进入 LlamaIndex 体系，其实是在回答一个更具体的问题：当模型不只是问答，而是围绕数据做多步知识工作时，该怎么组织。
这让 LlamaIndex 的 Agent 路线带有明显的数据气质。
它适合做知识密集型任务。比如企业知识库分析、文档处理、研究助理、数据检索和结构化整理。它的优势不在于通用编程 Agent，而在于让 Agent 更好地站在数据层上工作。
短板也相应存在。
如果任务需要复杂操作系统级执行、长周期代码修改、多工具权限控制，LlamaIndex 不是最自然的选择。它可以接，但不是它最锋利的地方。
7. 当前格局：不是一家独大，而是分层竞争
如果把这些玩家放到同一张图里，会发现 Agent Harness 不是单一赛道。
它至少分成四层。
第一层是模型供应商原生 harness。OpenAI 和 Anthropic 都在这里发力。优势是模型能力和工具接口结合紧，缺点是锁定。
第二层是开放工程 harness。LangChain / LangGraph 是代表。优势是控制权和可组合性，缺点是复杂。
第三层是企业编排 harness。Microsoft AutoGen、Semantic Kernel 这类更适合企业架构，优势是治理和生态，缺点是重。
第四层是垂直场景 harness。Claude Code 面向编程，LlamaIndex 面向知识和数据，CrewAI 面向团队流程和自动化原型。
所以当前不是「谁会赢」这么简单。
更现 实的问题是，你的 Agent 到底是哪一类任务。
如果是个人开发者写代码，Claude Code 这种产品级 harness 很强。
如果是企业要把 Agent 接进内部系统，LangGraph、Semantic Kernel、OpenAI Agents SDK 都可能进入选择。
如果是知识库和文档任务，LlamaIndex 的数据栈更自然。
如果是快速验证一套多角色自动化流程，CrewAI 会更顺手。
Harness 不是一个横向通吃的组件。
它正在变成 Agent 产品的生态位本身。
四、横纵交汇洞察
1. 历史塑造了当下：LangChain 为什么会最早把 harness 讲清楚
LangChain 能在 2026 年把 harness 这个概念讲得这么清楚，不是偶然。
它从诞生第一天就在做胶水层。
早期 LangChain 解决的是 LLM、工具、Prompt、检索之间怎么接。后来行业发现简单 chain 不够，于是 LangGraph 出来处理状态和流程。再后来 coding agent 和 deep agent 让复杂任务里的计划、文件系统、子 Agent、middleware 变得重要，Deep Agents 就顺理成章出现。
你看这条线，它没有突然转向。
它是同一个问题不断变深。
从接模型，到接工具。
从接工具，到接状态。
从接状态，到接长期记忆和执行策略。
从接执行策略，到争夺「谁拥有 Agent 工作流」。
这就是 LangChain 今天强调 open harness 的历史根源。它知道自己很难在闭源模型能力上和 OpenAI、Anthropic 正面打，所以它必须把价值放在模型之外：运行时、记忆、工具、评估、可迁移性。
2. 闭源产品和开放 harness 的真正分歧，不是功能多少
很多人讨论 OpenAI Agents SDK、Claude Agent SDK、LangGraph 时，会很自然地拿功能表对比。
有没有工具调用。
有没有 MCP。
有没有 tracing。
有没有 memory。
这些当然要看，但还不是最深的分歧。
真正的分歧是，Agent 的「经验」属于谁。
一个 Agent 用得越久，越会积累很多东西：用户偏好、组织流程、常见失败、工具使用习惯、项目结构理解、历史决策、内部术语、权限边界。这些东西不会全写在代码里，也不会全写在 prompt 里。它们散落在对话、文件、trace、memory、tool logs、eval cases 里。
这就是 harness 的沉淀物。
如果这些沉淀物留在开放 harness 里，企业和开发者可以迁移模型，可以换供应商，可以自己治理。
如果这些沉淀物留在闭源产品里，短期体验可能更好，但长期迁移成本会越来越高。
这不是简单的开源情怀。
这是资产归属问题。
3. Agent 的护城河，正在从「模型聪明」转向「过程可 控」
2023 年大家还在问，模型会不会自己完成目标。
2026 年更现实的问题是，模型出错时系统能不能发现，能不能止损，能不能恢复。
这就是 harness 的真正价值。
越是高价值任务，越不能只追求模型自由发挥。法律、金融、医疗、企业运维、代码发布、数据修改，这些场景里，Agent 做对九次、错一次都可能很麻烦。
所以护城河会从单次推理能力，慢慢转向过程治理能力。
谁能把模型的行动变成可审计、可回放、可评估、可中断、可授权的流程，谁就更接近生产级 Agent。
这也是为什么我不认为 harness 只是「模型外面的一层壳」。
它更像电力系统里的配电网。发电机再强，电如果不能稳定、安全、按需送到每个设备，用户感受到的仍然是停电。
模型是发电机。
Harness 是配电网。
4. 未来三种剧本
最可能的剧本，是混合 harness 成为主流。
企业和开发者不会只选一种。模型供应商原生 harness 会承担一部分通用工具和多模态能力，开放 harness 负责业务状态、长期记忆、审计和模型可替换性，MCP 负责工具连接。一个真实系统里可能同时有 OpenAI Agents SDK、LangGraph、内部权限系统和 MCP server。
这听起来不够性感，但工程世界经常就是这样。
最危险的剧本，是闭源 harness 吃掉工作记忆。
如果用户每天的任务、偏好、文件操作、工具轨迹、上下文压缩策略都沉到某个闭源 Agent 产品里，模型供应商就不只是卖模型，而是在掌握用户的工作方式。到那时换模型不难，换 harness 很难。因为你换掉的不只是 API，而是一整套被训练出来的工作习惯。
最乐观的剧本，是工具、记忆、技能和 trace 都出现更开放的可迁移标准。
MCP 已经在工具层开了个口子。未来如果 memory、skills、evaluation traces、permission policies 也能标准化一部分，Agent 生态就不会完全被少数闭源产品吸走。开发者可以把一个团队的 Agent 工作流从 Claude 迁到 OpenAI，从云端迁到本地，从一个框架迁到另一个框架。
这会让模型竞争回到模型，让 harness 竞争回到体验和工程质量。
5. 给开发者的判断框架
如果你现在要选 harness，不要先问哪个最火。
先问四个问题。
你的任务需要多长时间跨度。如果只是一次性问答，用不到重 harness。如果任务会跨文件、跨天、跨项目，状态和记忆就很重要。
你的任务能不能容忍错误。如果不能，就要优先看权限、审计、human-in-the-loop、trace 和回滚。
你的核心资产在哪里。如果核心资产是组织流程、用户记忆和内部工具，尽量不要让它们完全沉在闭源产品里。
你的团队有没有工程能力。如果没有，闭源产品和高层 SDK 更适合起步。如果有，LangGraph 这类开放 harness 能换来长期控制权。
我的总体判断是，Agent Harness 会成为未来两年 Agent 应用真正的分水岭。
模 型差距还会存在，但应用差距会越来越多地来自模型外面。
谁能把模型放进一个好系统里，谁才真正拥有 Agent。
五、信息来源
访问时间均为 2026-04-24。
| 类型 | 来源 | 用途 |
|---|---|---|
| 核心文章 | LangChain, The Anatomy of an Agent Harness, https://blog.langchain.com/the-anatomy-of-an-agent-harness/ | Agent Harness 定义、组件拆解、Terminal Bench 2.0 harness engineering 案例 |
| LangChain 延伸 | LangChain, Your Harness, Your Memory, https://www.langchain.com/blog/your-harness-your-memory | 开放 harness 与长期记忆归属 |
| LangGraph 文档 | LangChain Docs, LangGraph overview, https://docs.langchain.com/oss/python/langgraph/overview | 状态、持久执行、human-in-the-loop、Agent 运行时 |
| Deep Agents | LangChain Docs / Deep Agents, https://docs.langchain.com/oss/python/deepagents/overview | planning、filesystem、subagents 等 harness 模式 |
| OpenAI | OpenAI Agents SDK, https://openai.github.io/openai-agents-python/ | OpenAI 原生 Agent SDK 的 primitives |
| OpenAI | OpenAI Platform Docs, Responses / Tools / Agents 相关文档, https://platform.openai.com/docs | 模型供应商原生工具与 Agent 运行能力 |
| Anthropic | Introducing the Model Context Protocol, https://www.anthropic.com/news/model-context-protocol | MCP 作为工具接入开放标准 |
| Anthropic | Claude Code / Claude Agent SDK docs, https://docs.anthropic.com/en/docs/claude-code/sdk | 编程 Agent SDK 和产品化 harness |
| Microsoft | AutoGen Documentation, https://microsoft.github.io/autogen/stable/ | 多 Agent、事件驱动、分布式 agentic applications |
| Microsoft | Semantic Kernel Agent Framework, https://learn.microsoft.com/en-us/semantic-kernel/frameworks/agent/ | 企业 Agent 框架、plugin 和编排 |
| CrewAI | CrewAI Documentation, https://docs.crewai.com/ | agents、tasks、crews、flows 抽象 |
| LlamaIndex | LlamaIndex Agents docs, https://docs.llamaindex.ai/en/stable/use_cases/agents/ | 数据 / 知识工作场景下的 Agent |
| 学术论文 | ReAct: Synergizing Reasoning and Acting in Language Models, https://arxiv.org/abs/2210.03629 | 推理与行动循环的早期范式 |
| 学术论文 | Toolformer: Language Models Can Teach Themselves to Use Tools, https://arxiv.org/abs/2302.04761 | 模型工具使用能力的早期研究 |
| 学术论文 | Chain-of-Thought Prompting Elicits Reasoning in Large Language Models, https://arxiv.org/abs/2201.11903 | 推理轨迹作为 Agent 行动前置能力 |