什么是代理框架？Claude Code、DeepSeek Harness以及Hermes Agent背后的架构原理是什么

2026年8月13日，DeepSeek在GitHub上发布了一个名为deepseek-harness的仓库。仅仅两天后，这个仓库就获得了95,386个星标和8,826次分支请求——这一数字本身虽然算不上什么具有实际意义的指标，但如此迅速的增长速度显然说明其成功并非偶然。在2026年，这款开发工具在GitHub上的增长速度堪称最快的之一（例如Flowtivity和deepseek-ai/deepseek-harness）。

九个月前，一位名叫Mario Zechner的奥地利工程师发布了一个完全相反的产品：一款名为Pi的编程辅助工具，它仅配备了四项内置功能，除此之外几乎没有其他附加组件。Pi经历了大约一年的缓慢发展，才最终获得了91,600个星标——这一增长过程完全依靠那些尝试使用它并持续使用它的开发者的推动，而没有出现任何突然的爆发式增长。earendil-works/pi。

因此，我们看到了两种截然不同的发展轨迹，它们背后也体现了完全不同的设计理念。然而，在这两种方案的名称中，都包含了一个相同的词：harness（即“辅助工具”或“框架”）。

如果你们在任何程度上使用人工智能辅助工具进行开发，那么这个词就必然会出现在你们的讨论中。而大多数关于它的解释，要么只是营销宣传用语，要么就是那些布满各种箭头的图表。

本文将明确什么是“辅助工具”，并对比目前最受欢迎的十款此类工具——从Claude Code到DeepSeek Harness再到Pi——分析它们所遵循的相同五层架构设计。

读完这篇文章后，你们就会明白为什么今年在开发者的讨论中，“辅助工具”这个词取代了“框架”这一术语；同时也会了解那些在2026年最受关注的辅助工具，在其品牌定位上究竟有哪些差异。此外，你们还会获得一个由60行Python代码构成的简单辅助工具示例，以及对其相关技术架构的详细解析（包括MCP、编排系统、可观测性组件等），同时还会有一个帮助你们为团队选择合适辅助工具的决策指南。

目录

• 什么是辅助工具？

• 从“代理框架”到“辅助工具”：发生了什么变化

• 各类辅助工具解决方案一览

• 关于辅助工具应如何运作的三种不同设计理念

• 用不到60行Python代码构建一个简单的辅助工具

• 辅助工具的技术架构组成

• 为什么炒作曲线与实际采用率曲线会出现分歧

• 如何为你的团队选择合适的辅助工具

• 无论哪种辅助工具最终胜出，哪些核心功能都是会被保留下来的

• 结论

• 接下来应该探索什么

什么是智能体框架？

智能体框架其实就是包裹在大型语言模型之外的运行时外壳。该模型本身只负责一件事：当接收到一段文本以及一系列可用的工具时，它会预测接下来应该说什么或使用哪个工具。而其余的所有工作都由智能体框架来完成。

这个看似平凡、其实相当复杂的系统包括以下几个部分：用于调用模型的循环结构、用于执行各种工具的代码、用于在多轮交互中保持上下文信息的记忆机制，以及用于保护文件系统的安全沙箱。正是这些基础设施决定了智能体在遇到工具调用失败时是能够恢复运行，还是直接陷入瘫痪。

图1：每个智能体框架都必须包含的五个组成部分，这些组件以循环结构围绕模型核心进行排列。模型位于中心，仅负责预测下一条消息或应使用的工具；周围的部分包括：用于将请求转发到文件系统、外壳程序或外部API的工具路由器，用于保留上下文信息的内存层，在执行前将大型任务分解为多个步骤的规划层，以及限制工具使用范围的沙箱边界。

循环结构中的箭头表示模型的输出会被作为下一轮交互的输入重新传入模型，正是这种机制使得单一的预测结果能够被转化为持续运行的智能体，直到任务完成。

有一位从业者从另一个角度对智能体框架的功能进行了描述：智能体框架提供了模型本身无法完成的所有功能——它负责将计划转化为实际行动、提供对终端、文件系统等工具的访问权限、确保上下文信息在多轮交互中得以保留、协调它所创建的子智能体的工作，同时还规定了这些子智能体可以使用的功能范围（CellCog）。

具体来说，当你在Claude Code、Cursor或Aider中输入请求时，系统会按以下顺序执行相应操作：

1. 智能体框架会首先构建一个交互提示：其中包含你的请求内容、系统的指令，以及模型可以使用的工具列表。

2. 然后模型会作出响应，通常会以文本形式给出推理结果，并同时调用一个或多个工具（例如read_file、run_bash或edit等）来执行具体操作。

3. 智能体框架会在安全沙箱环境中执行这些工具命令，并捕获它们的输出结果。

4. 随后，框架会将工具的输出结果重新加入对话内容中，并再次调用模型进行下一步处理。

5. 这个循环会持续进行，有时甚至会重复数十轮，直到模型产生最终答案，或者直到达到轮次限制、成本上限，又或者是有人手动中断了这一过程。

这种由五个步骤组成的循环机制，有时也被称作“智能体循环”或“ReAct循环”（这一名称来源于2022年那篇首次将推理与行动视为一个相互交织的过程进行描述的论文：Yao等人），是目前市场上所有智能体工具所共同采用的核心机制。 真正决定某种智能体工具是否能够有效地完成其任务的关键因素，在于步骤3和步骤4所涉及的所有环节：在执行任务之前，规划工作的质量如何；当上下文信息不断变化时，内存系统该如何决定保留哪些信息、丢弃哪些信息；沙盒环境的隔离程度如何；以及该工具是否能够创建一个较小的子版本来处理某些子任务，而不会干扰主流程的运行。 如果这些环节中的任何一个出问题，从外部观察来看，其表现症状都是完全相同的：智能体会陷入停滞状态，忘记自己原本要执行的任务，或者在一个本来只需要进行五轮操作的 task 上耗尽所有的资源。

从智能体框架到智能体工具：发生了哪些变化

从2023年到2025年，“框架”这个词在智能体技术领域占据了主导地位。当时流行的工具包括LangChain、AutoGen和CrewAI等。那个时代的“框架”实际上就是一些库文件——用户可以从中导入各种组件，选择自己需要的模型函数，然后自行编写逻辑代码来协调这些组件的运行。 而智能体工具则是一种截然不同的产品类型。这类工具已经将上述循环机制预先构建好了，它们在内存管理、规划策略以及安全性方面都有一套固定的设计思路。用户只需通过运行相应的命令即可与这些工具进行交互。 Anthropic公司的Claude Code在2025年之前就彻底改变了这一发展趋势：这款终端原生型智能体能够自动完成计划任务、编辑文件、运行测试以及提交代码，而用户完全不需要编写任何逻辑协调代码。 到了2026年，这种“预先构建好循环机制”的设计模式已经出现在下表中列出的十种智能体工具中，从Claude Code到DeepSeek Harness再到Cline，所有这些工具都被统称为“智能体工具”，而不再被称为用户需要自行组装的“框架”。 从它们的命名方式就可以看出这一变化：DeepSeek自己的代码仓库就被命名为deepseek-harness，这显然体现了从“框架”到“智能体工具”的转变。 LangChain的Deep Agents项目也表明，现在整个行业已经将“智能体工具”视为一种独立的架构层次。开发这些工具的目的在于逆向分析Claude Code之所以成功的原因，并将其设计理念重新构建为一个开放、不受特定模型限制的库系统。 LangChain自己对这一项目的解释归结为Harrison Chase提出的那个问题：“究竟是Claude Code的哪些特性使其具备了通用性？我们能否将这些特性抽象出来并推广到其他场景中？” 对于LangChain来说，这个项目也具有明显的商业价值：它正在提供一种替代现有工具的选择，而它所提到的那四种核心机制，无论由谁来命名，都依然具有普遍意义。 Deep Agents明确指出了Claude Code的智能体工具所依赖的四种具体机制：

• 一种规划工具，它要求模型在操作任何文件之前先明确说明自己需要执行的步骤。这种机制能够有效防止模型在长时间运行过程中逐渐偏离最初的任务目标。

• 虚拟文件系统与沙箱环境，为代理程序提供了结构化、隔离式的读写接口，使其能够安全地访问存储库中的数据。

• 子代理机制：主代理会创建一个拥有独立上下文环境的子代理来处理特定的任务，然后该子代理会将执行结果反馈给主代理。

• 上下文与内存管理功能，包括用于压缩对话记录的中间件，以及用于分流大型工具输出数据的机制，这些措施能够确保长时间运行不会导致模型的上下文窗口被占用过多（参考：LangChain）。

这份清单值得记住，因为这四种机制（规划、沙箱测试、任务委托以及上下文管理）是每一个严肃开发的工具框架都必须解决的问题，无论“Deep Agents”是否仍被视为人们首选的工具框架。其他的一切都只是品牌宣传而已。

一目了然的智能体开发工具框架解决方案

下表列出了截至2026年8月最受开发者关注的那些工具框架，以及它们各自所依赖的架构设计理念。

工具框架	开发团队	优化方向	值得注意的特点
Claude Code	Anthropic	支持端到端的编码流程：规划、编辑、测试、提交代码	率先采用了“规划工具+子智能体”的架构模式，如今其他竞争者都在模仿这一设计
DeepSeek Harness (dsh)	DeepSeek AI	强调运行时模块化的设计理念	在短短两天内就获得了95,000个GitHub星标。该工具框架的每一个组件、模型、工具以及沙箱环境都是可替换的插件（更多信息请访问GitHub）。
Deep Agents	LangChain	能够灵活复用Claude Code的工具框架架构	以开源库的形式提供，同时配备了命令行界面；可以与任何调用模型的工具配合使用（更多信息请访问LangChain）
Hermes Agent	Nous Research	一种能够跨多个平台运行的、具备自我优化能力的智能体辅助工具	支持Telegram、Slack、Discord、WhatsApp以及电子邮件等多种沟通平台；同时还提供了一个可供大家共享技能的公共平台（更多信息请访问Nous Research，或GitHub仓库GitHub）
Pi	Mario Zechner / Earendil Inc.	极简主义设计：仅内置了四种基础工具，其余功能均为可选的TypeScript扩展模块	通过自然增长的方式获得了超过91,600个GitHub星标（更多信息请访问GitHub）
Oh-My-Pi (omp)	Can Bölük	对Pi工具框架进行了大幅扩展，使其能够在集成开发环境中使用：支持LSP诊断功能、通过DAP进行调试，同时还提供了持久化的执行环境	该工具框架的引擎是用Rust语言重新编写的；目前提供了60多种模型接口以及31种内置工具（更多信息请访问GitHub）
CellCog	CellCog	一款适用于各种知识处理任务的通用型智能体开发工具框架	截至2026年8月，在DeepResearch Bench测试中排名第一（得分55.78）；该工具框架的同一引擎中就内置了视频、图片和文档输出功能（更多信息请访问CellCog）
OpenHands	All Hands AI	一款基于Docker技术的开源工具框架，内置了bash命令行、浏览器以及测试执行功能	该工具框架最初被命名为OpenDevin；默认情况下，每个沙箱环境都会将shell命令和文件写入操作与主机系统隔离开来（更多信息请访问OpenHands文档）
Aider	Paul Gauthier及其团队	支持Git原生的协作编程模式，每个开发步骤都会生成清晰、可供审核的代码提交记录	深受那些希望拥有高效代码差异审查流程的工程师们的喜爱
Cline	Cline Bot Inc.及其团队	一款与模型类型无关的VS Code扩展插件，需要经过审批才能执行文件编辑操作	默认情况下，每次修改文件或执行命令之前都会暂停，等待用户确认后才会继续执行

其中一些方法是专门为编程设计的，而另外一些方法（尤其是CellCog和Hermes Agent）则试图将这种模式应用到编程之外的更广泛的认知工作中。

专为编程设计的工具会以代码仓库、测试套件以及差异对比结果作为其工作单元；而对于用于一般认知工作的工具来说，就需要为研究、写作以及多步骤业务任务设计相应的结构，而这无疑是一个更加困难且缺乏标准化规范的问题。

如果你正在评估某种工具是否适用于编程之外的领域，那么首先应该问：它的基本工作单元是什么？是否有人为它设计了类似的差异对比机制，还是仅仅假设这种机制是存在的呢？

关于工具应如何运作的三种竞争性理念

抛开营销宣传成分来看，2026年这一年度中各种代理工具的蓬勃发展实际上背后蕴含着三种不同的工程理念。

图2：三种不同的工具设计理念，以三列并排的形式呈现。第一列是DeepSeek Harness，它的核心是一个插件内核，模型、沙箱环境、内存资源以及用户界面都是可以互换的模块。

第二列包括Claude Code和Deep Agents，它们的设计围绕四种固定机制展开：规划、虚拟文件系统、子代理以及上下文压缩。

第三列则是Hermes Agent，它的特点在于拥有一个会随着任务完成而不断扩展的技能库。这三列工具只有图1中展示的基础框架是相同的，其余部分都体现了不同的设计理念，这些理念旨在让工具能够在长时间运行过程中保持稳定性。

理念一：一切都是插件。

DeepSeek Harness建立在名为Cordis的元框架之上。DeepSeek在他们的论文《一种用于实现时空组合性的编程范式》中详细描述了这一框架的设计思路，其核心思想就是：在运行时，所有组件都可以被替换。deepseek-ai/deepseek-harness

在实际应用中，这意味着模型、沙箱环境、会话存储机制、调度循环，甚至用户界面主题，都属于可更换的模块。该工具还提供了“创建模式”，允许用户查看正在运行的系统，在内存中测试Cordis插件，并将它们组合成新的配置方案。DeepSeek

这种设计理念的核心在于：没有哪种架构能够永远占据优势，因此最好的策略就是将架构本身也视为一个可配置的文件。

理念二：一套简洁、固定的机制，要运用得当。

Claude Code以及后续的LangChain Deep Agents采取了相反的策略：他们选择了四种机制（规划、沙箱式文件系统访问、子代理委托机制以及上下文压缩技术），并致力于提升这些机制的可靠性。

这份列表中的每一种机制都十分常见，以至于许多竞争者都会直接将其借鉴使用。上表中提到，正是Claude Code使得“规划加子代理”的模式得以普及，如今其他系统也在效仿这一模式。这种策略之所以有效，是因为在每一项任务中，这四种机制都是同时运行的。如果省略其中任何一种机制，其余的机制可以在一段时间内弥补其缺失，但长时间使用后，问题最终还是会暴露出来。

第三种策略：能够累积效果的内存机制。

Hermes Agent认为，目前最大的未解决问题在于不同会话之间的衔接。大多数系统在每次新对话开始时都会将上下文重置为初始状态，而Hermes则允许用户在解决复杂问题后将这些解决方案保存为可重复使用的技能。之后，在处理类似的请求时，系统会先从这些保存的技能库中查找相应的解决方案，从而提高处理重复性任务的效率。Nous Research

这种设计既有优势，也存在风险：如果技能库不受控制地持续扩大，最终可能会成为一种“负担”，其存在的意义也会被遗忘。结合Telegram、Slack和Discord等平台提供的原生调度功能与通道集成能力，这一设计的目标更接近于打造一个长期运行在服务器上的智能助手，而不仅仅是一个为了一次性会话而开发的工具。

第四种策略贯穿于前三种策略之中：Pi和Oh-My-Pi认为，其他系统所添加的许多功能其实都是多余的累赘，对于那些清楚自己需求的技术人员来说，使用四款工具再加上一个扩展系统，反而比使用功能完备的平台更有效。

Pi在GitHub上获得了超过91,600个星标，这一成就主要是通过用户口口相传的方式实现的，而非通过大规模的宣传活动，这说明这种策略确实具有持久的影响力。

这四种策略都有其合理性。它们分别针对不同的失败模式进行了优化：DeepSeek Harness旨在解决架构锁定问题；Claude Code和Deep Agents致力于提升长时间会话中的系统稳定性；Hermes则致力于避免在不同会话中重复进行相同的工作；而Pi则致力于减少系统的臃肿程度。

因此，在选择其中某一种策略之前，先思考一下目前哪种失败模式正在耗费你的时间。这个问题的答案将帮助你选出最适合自己的工具。

用不到60行Python代码构建一个最小化的工具框架

下面的示例使用了Anthropic的Messages API，按照图1中描述的五步流程来构建了一个工具框架：其中包括一个模型、三个辅助工具，以及一个循环机制，这个循环会不断调用模型，直到模型不再需要使用这些辅助工具为止。你会看到，在这短短60行代码中，实际上包含了本节讨论的所有失败模式对应的处理逻辑。

import subprocess from anthropic import Anthropic client = Anthropic() TOOLS = [ { "name": "read_file", "description": "从工作目录中读取一个UTF-8格式的文本文件。", "input_schema": { "type": "object", "properties": {"path": {"type": "string"}, "required": ["path"], }, }, { "name": "write_file", "description": "将内容写入文件，如果文件已存在则会覆盖原有内容。", "input_schema": { "type": "object", "properties": { "path": {"type": "string"}, "content": {"type": "string"}, }, "required": ["path", "content"], }, }, { "name": "run_bash", "description": "在沙箱目录中运行shell命令并返回其执行结果。", "input_schema": { "type": "object", "properties": {"command": {"type": "string"}, "required": ["command"], }, }, ] def execute_tool(name, tool_input): if name == "read_file": return open/tool_input["path']).read() if name == "write_file": with open TOOL_input["path"], "w") as f: f.write-tool_input["content"]) return f"已向{tool_input['path']}写入{len(tool_input['content'])}字节的内容" if name == "run_bash": result = subprocess.run( tool_input["command"], shell=True, cwd="./sandbox", capture_output=True, text=True, timeout=30, ) return result.stdout + result.stderr raise ValueError(f"未知的工具：{name}") def run_harness(task, max_turns=15): messages = [{"role": "user", "content": task}] for _ in range(max_turns): response = client.messages.create( model="claude-sonnet-5", max_tokens=4096, tools=TOOLS, messages=messages, ) messages.append({"role": "assistant", "content": response.content}) if response.stop_reason != "tool_use": return response.content[0].text tool_results = [] for block in response.content: if block.type == "tool_use": output = execute_tool(block.name, block.input) tool_results.append({ "type": "tool_result", "tool_use_id": block.id, "content": output, }) messages.append({"role": "user", "content": tool_results}) return "已停止：在达到最大尝试次数后仍未得到最终答案"

运行 `run_harness("在 sandbox/hello.py 中编写一段 Python 脚本，该脚本应输出前 10 个斐波那契数，然后运行它并展示输出结果。")`，观察整个过程的发展：模型会先生成这个文件，接着调用 `run_bash` 来执行它，之后读取输出结果，最后才给出最终的文本答案。上面表格中列出的每一个生产环境框架，其实都是这种基本结构的改进版本。

Claude Code 在第一步之前增加了规划环节，在每次调用 `run_bash` 之前也会设置权限检查。Deep Agents 配备了虚拟文件系统，并添加了一个中间层，在数据量超过模型的处理范围之前对消息进行压缩处理。DeepSeek Harness 则允许在运行时更换 `TOOLS` 列表或模型客户端程序本身。

这种简单的循环结构与真正成熟的环境之间的差距，完全体现在可靠性工程方面：当某个工具调用失败时会发生什么？在第 50 步时会怎样？又是什么机制能阻止沙箱环境访问 `./sandbox` 目录之外的资源？

在 `execute_tool` 中，并没有任何机制能够检测到格式错误的响应或出现故障的工具，因此如果有一个工具出现了问题，整个系统就会反复陷入同样的错误状态。你需要自行添加重试机制，否则系统会默认持续尝试执行这些操作。

这个例子中有两点值得仔细研究。首先，`cwd="./sandbox"` 这一行代码起到了至关重要的作用：如果没有它，`run_bash` 就可以执行主机用户能够执行的任何命令，因此所有正式的生产环境框架都会将工具执行过程限制在容器或受限目录内。在代码重构过程中，这条代码很容易被意外删除，而一旦丢失，就会带来严重的后果。

其次，设置 `max_turns=15` 是因为当前的设计并没有让模型自行停止执行。如果省略这一限制，那么系统就会无限循环下去，只要模型还在请求工具，就会不断消耗令牌。如果在代码重构时忘记了这条配置，从外部看，问题表现得和正常情况完全一样：任务永远无法完成，令牌消耗量也会持续上升，直到有人手动终止这个进程。

代理环境框架解决方案栈

一个环境框架并不是独立运行的。在几乎所有的正式代理环境中部署时，都会涉及到三层相互关联的结构。了解每一层的功能范围以及它们之间的交互关系，才能确保让环境框架去解决属于更高层次的问题。如果忽略了这种层级的对应关系，你就会花费大量时间去调试那些实际上存在于较低层次层面的问题。

图3：由四层水平结构组成，这些层次从下到上依次排列。最底层是协议层，也就是模型上下文协议（MCP）。这一通用标准使得任何工具都能以相同的方式与外部工具或数据源进行交互。第二层是具体的工具框架，也就是图1中所示的那些循环结构。

第三层是编排框架，它们位于单个智能体工具框架之上，用于协调多个智能体或长时间运行的状态化工作流程。LangGraph、CrewAI、AG2、Mastra和DSPy都属于这一层。

最顶层由两个侧边面板组成，而不是第四个水平条带。这一层负责提供观测能力和沙箱环境：Langfuse和LangSmith等工具可以监控下层的所有运行情况，而E2B和Modal则能为这些工具框架提供隔离的执行环境。

协议层：MCP

模型上下文协议是一种开放标准，最初由Anthropic在2024年11月推出，旨在以统一的方式将模型与外部工具、文件和数据源连接起来Anthropic官网）。到了2025年底，这一标准被纳入了Linux基金会的Agentic AI基金会，并得到了Anthropic、OpenAI和Block等机构的支持维基百科。

通常情况下，一个工具框架会从MCP配置文件中加载所需的工具列表，而不是通过手动编写的代码来获取这些信息：

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/you/project"]
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres", "postgresql://localhost/mydb"]
    }
  }
}

你在这里添加的每一个MCP服务器都会自动成为TOOLS目录中的可用工具，而你完全不需要编写任何新的execute_tool函数。只需编写一次集成代码，之后任何兼容MCP的工具框架——无论是Claude Code、Deep Agents、DeepSeek Harness，还是你自己开发的工具——都可以使用这一功能。这就是协议层存在的全部意义。

编排层

一个工具框架通常会通过单一的循环结构来运行一个智能体。但当你需要多个智能体协同完成某个状态化、长时间运行的工作流程，并且这些智能体需要承担不同的角色（比如规划者、研究员或审核员）时，你就需要使用编排框架了。选择错误的编排框架可能会导致你花费数月的时间来解决问题，而不仅仅是需要修改几行代码。

1. LangGraph：这种框架将多智能体工作流程建模为图结构，并支持检查点和时间回溯调试功能，在许多受监管的企业中被广泛用于状态化生产工作流程GitHub官网

2. CrewAI：这种框架通过根据角色来定义智能体，使它们能够协作完成共同任务

3. AG2：这是由社区维护的框架，它是微软最初开发的AutoGen项目的继承者。从2026年开始，AG2采用了异步、事件驱动的运行机制，并基于可组合的中间件进行开发GitHub官网, pickaxe.co网站

4. Mastra：这是一种以TypeScript为开发语言的智能体框架。在2026年1月发布1.0版本后，它的GitHub星标数量超过了22,000个，每周通过npm下载的次数也达到了300,000次pickaxe.co网站, GitHub官网

5. DSPy：这是斯坦福大学NLP团队开发的框架。它将提示工程视为一种更接近于编译的过程，而不是手工编写代码，会根据特定的评估指标来优化生成的建议GitHub官网

可观测性与沙箱环境

一旦某个代理程序自主进行了工具调用，你就需要了解它具体做了什么、在何处进行了这些操作，这样才能避免盲目地进行调试。Langfuse与LangSmith能够追踪整个会话过程中所有的模型调用、工具调用以及相关成本信息，正是通过这种方式，你才能调试那些在第34步时出现故障的代理程序(GitHub, LangChain)。

Braintrust与Arize Phoenix在这种追踪功能的基础上，还提供了更为严格的评估机制，因此你可以像测试代码库一样，对代理程序的行为进行回归测试(Braintrust, Arize-ai/phoenix)。而对于沙箱环境本身来说，E2B与Modal提供了可临时使用的微型虚拟机，在这种环境中，以run_bash风格进行的工具调用可以不受主机系统的影响而正常运行(GitHub, Modal)。

为何炒作曲线与采用曲线会出现分歧

图4：在相同的坐标轴上绘制出的两个项目在大约400天内的GitHub星数变化曲线。DeepSeek Harness的曲线几乎呈垂直状：在2026年8月13日发布后的前两天内，其星数骤增到了95,000颗以上，之后则趋于平稳。

而Pi的曲线则完全不同：从2025年8月发布开始，它的星数就呈缓慢、稳定的上升趋势，一年后终于达到了91,600颗星，其增长过程中没有任何突然的峰值。

将这两条曲线放在同一张图表上展示，目的就在于说明它们达到相同结果的过程是不同的：一条曲线反映的是一次有组织的发布活动以及恰到好处的宣传推广；而另一条曲线则反映了整整一年时间里，工程师们逐一决定是否继续使用这个工具。

项目发布初期星数的急剧增加说明它引起了人们的关注；而持续的使用情况则能告诉你，六个月后这个工具是否仍然被人们频繁使用。这两者是不同的问题，其背后的原因也各不相同。

DeepSeek Harness在两天内就获得了95,000颗GitHub星数这一数据是可验证的(Flowtivity)，但这一结果在很大程度上也得益于发布时机、推广策略以及该工具所针对的目标用户群体。

Pi工具在用户数量方面取得的类似增长，其实传递了另一种信息：有一年时间里，根本没有人专门组织过推广活动来推动它的使用。这种普及主要是通过工程师们口口相传实现的——那些尝试过这个四工具编码辅助工具的工程师们继续使用它，并将体验推荐给了其他同事。

某个工具在发布初期表现得很出色，但在使用三个月后，如果维护人员转而去关注其他新工具，那么这个工具仍然会让团队陷入困境。这两者并没有哪一方更重要；但如果你要选择某个工具来支持团队的工作流程，那么你应该研究它的长期发展趋势，而不仅仅是它当前的表现如何。

如果某个工具在初期表现出急剧的增长势头，但随后增长速度放缓，这说明有一个活跃的社区正在围绕这个工具形成——在将生产环境的工作流程依赖于它之前，观察这一现象是很有必要的。而如果一个工具的使用量持续稳定地增加，这说明工程师们在最初的热情消退后仍然继续使用它，这种趋势虽然发展得较慢，但更为可靠。

如何为你的团队选择合适的编码辅助工具

在选择工具时，应该根据团队当前面临的具体问题来挑选，而不是看哪种工具目前最受欢迎。如果仅仅因为某个工具的用户数量多就选择它，那么之后团队可能会花费数周的时间来进行迁移工作，这种做法是错误的。

• 如果你需要一个能够可靠地完成整个编码任务的辅助工具，那么Claude Code、Deep Agents或Aider都是不错的选择。这三款工具都能很好地实现图1中描述的“规划+沙箱测试”模式。

• 如果你担心会被某个供应商或某种技术架构所束缚，并且预计会经常更换这些工具，那么DeepSeek Harness的插件化设计以及Deep Agents对特定模型的不依赖性，正好能解决你的顾虑。任何将某个供应商的SDK硬编码到核心代码中的工具都不适合这种需求。

• 如果某些类型的任务会在数周或数月内反复出现，那么你需要一个能够帮助工具逐渐提高处理这些任务效率的工具。Hermes Agent的技能库正是为这类场景设计的；特别是如果你希望团队能够通过聊天平台直接使用这个工具的话，这一点就更加重要了。

• 如果你希望降低出错的风险，并且愿意自己为那些缺失的功能编写扩展程序，那么Pi的四工具核心架构或者Oh-My-Pi都是不错的选择。后者还提供了IDE级别的开发工具、代码格式检查功能以及调试器。

• 如果你的团队需要多个辅助工具来协同完成一个耗时较长且需要维护状态的信息处理流程，那么LangGraph、CrewAI、AG2或Mastraka这类工具会更适合你的需求。

无论你选择哪种工具，都应该从一开始就把它作为不可或缺的一部分来使用。如果一个辅助工具在无人监控的情况下运行30分钟后就出现了故障，那么之后进行调试将会变得非常困难，而且根本找不到故障的原因；而如果使用Langfuse或LangSmith这样的工具，同样的故障可能只需要5分钟就能解决。为了节省一些设置时间而忽略这个步骤，那么一旦有辅助工具在运行过程中出现故障，你就会付出沉重的代价——因为到时候根本没人能够解释为什么会出现这种问题。

无论哪种框架获胜，哪些技术都是不可或缺的

本文中提到的具体工具名称可能在一年内就会变得过时，因为这个技术领域的发展速度实在太快了。但图1中展示的五步循环结构、LangChain在Claude Code的架构中发现的四种机制，以及图3中的分层架构模型，这些内容仍然具有实用性。

接下来一个月如果出现任何新的工具框架，你可以根据这三种参考标准来判断：它是否在技术架构上实现了创新，还是只是用不同的插件系统和更夸张的宣传手段对原有的技术进行了重新包装而已。

这种能力才是真正值得掌握的——关注技术架构本身，而不是营销宣传内容。无论工具名称如何快速更新，这个领域的基本原理是不会过时的。

结论

“代理框架”并不是某种神秘的新类型软件。它实际上是一种运行时环境，它能够将模型生成的下一步预测结果转化为一个能够进行规划、执行操作、检查自身工作并持续完成任务的实际系统。

所有代理框架都是由五个基本组成部分构成的，这些组件在任何实现方案中都会出现：循环结构、工具路由机制、内存管理模块、规划系统以及沙箱边界设置。2026年，真正发生变化的是这些组件的规模和性能。

现在已经有太多团队发布了各自的实现方案，它们之间的架构差异已经值得被深入研究。当前这个领域的技术体系涵盖了从DeepSeek那种依赖插件来实现所有功能的框架，到Pi那种极简主义的设计理念，再到Hermes Agent所具备的复合技能机制，以及Claude Code和Deep Agents中的四种固定功能模块。

上一节提供的数据也证明了这一点：在短短两天内，就有95,000人给这个技术给予了好评；而在一年内，这一数字增加到了91,600。这些数据说明，尽管工具名称在不断变化，但人们最终得出的结论却是相同的。

你自己试着编写一个只有60行代码的简单代理框架，观察它的运行过程吧。一旦你做到了这一点，市场上所有的代理框架都会不再显得那么神奇，而会变成你可以根据其技术特点来评估的实际工程产品。

接下来应该探索什么

• GitHub上的DeepSeek框架：阅读该项目中的README文件，了解Cordis插件的具体架构设计。

• LangChain的Deep Agents上下文工程文档：了解上述提到的自动压缩和卸载中间件在底层是如何工作的。

• 模型上下文协议规范：这个协议层是所有代理框架都可以接入的基础。

• Hermes Agent的技能文档

  ：了解复合技能库是如何被编写和复用的。

• LangGraph

  ：当单个代理框架已经无法满足需求时，LangGraph就是下一步的发展方向。

• E2B

  ：这是一个将工具执行过程隔离在沙箱环境中的实用工具。

<请访问我的GitHub账户，查看我利用这种专为人工智能设计的工程流程开发并分享的30多种开源软件解决方案及开发者工具。