> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# 我写了个能长期运行的编码代理
- URL: https://www.hubwiz.com/blog/i-built-a-long-running-coding-agent/
- Published: 2026-05-08T18:32:42.000Z
- Updated: 2026-10-13T15:49:29.000Z
- Description: Compound-Agent仍在开发中，但已经在生产中使用，并已经在推动我的几个项目。我正试图将我找到的所有最新应用AI研究和我的所有经验融入其中。
- Author: admin
- Tags: AGENT, COMPOUND-AGENT, #Import 2026-10-14 14:41

我花了数周时间为更高效的智能体AI编码构建了一个框架，推动模型进行越来越长的自主会话。结果是 `compound-agent`：一个开源的npm包，为智能体软件工作安装开发环境。它仍在开发中，但已经在生产中使用，并已经在推动我的几个项目。我正试图将我找到的所有最新应用AI研究和我的所有经验融入其中。

其背后的论点很简单：编码智能体的限制更多来自我们将其投入的环境，而非原始模型质量。

给智能体一个混乱的代码仓库、薄弱的反馈和没有持久记忆，它看起来就不可靠。给它一个能记住决策、暴露清晰任务边界并强制验证的代码库，同级别的模型就会变得有用得多。目标是让代码仓库本身承担更多的记忆、组织和检查工作。将上下文外部化，减少对提示和任何单一智能体的依赖，以驱动长时间的、自主的、可靠的工作。

这不仅仅是我的直觉。OpenAI、Anthropic和Cursor各自在2026年初运行了大规模智能体编码项目，并指向了同一个方向：瓶颈不在于代码生成，而在于环境设计、任务分解和让智能体可靠工作的反馈循环。（[OpenAI](https://openai.com/index/harness-engineering/?ref=hubwiz.com)、[Anthropic](https://www.anthropic.com/engineering/building-c-compiler?ref=hubwiz.com)、[Cursor](https://cursor.com/blog/self-driving-codebases?ref=hubwiz.com)）

## 1、从两个约束到三个需求

我认为当前智能体有两个结构性约束，它们塑造了一切。

第一个是有限的工作记忆。智能体只能看到适合当前上下文窗口的代码库片段。人类开发者在数周内构建项目的内部地图。智能体每次会话只从为其准备的上下文开始。

第二个是失忆。当会话结束时，记忆就消失了。决策、失败的方法、命名约定和来之不易的修复，除非被写到了某个持久的地方，否则都会消失。

因此，如果我们想减少这些约束的影响，我们需要让智能体在会话之间可以互换。状态必须存在于代码仓库中。这促使我定义了三个需求。

**记忆。** 项目应该积累知识，而不仅仅是代码。决策、经验和约定需要存储在下一个会话可以检索的地方。

**反馈循环。** 智能体需要机械化的方式来知道自己是否正确。测试、lint、类型检查和审查关卡不能停留在非正式层面——如果输出要规模化的话。

**可导航的结构。** 智能体在定位方向上浪费大量性能。任务需要明确的依赖关系、清晰的入口点，以及足够小到可以在一次推理中理解的范围。

将这三个理念构建到代码仓库本身，而不是仅依赖提示工程，可以消除由有限记忆和失忆导致的失败：重复的错误、薄弱的局部推理，以及花费太多时间重新发现项目约定。

## 2、compound-agent 安装了什么

`compound-agent` 将这三个需求打包成一个系统。

底层是 [Beads](https://github.com/steveyegge/beads?ref=hubwiz.com)，一个基于git的任务追踪器，将工作项直接存储在代码仓库中。`compound-agent` 将这些用作具有明确依赖关系的有范围的工作单元。这为系统提供了依赖图和对一个基本问题的可靠答案：现在到底什么可以真正开始工作？这就是可导航结构需求。

### 2.1 语义记忆

在它之上是语义记忆。早期我将所有内容存储在一个桶中（经验、文档、研究），检索结果很嘈杂。寻找快速模式修复的智能体会拉入架构文档。需要设计上下文的智能体会得到会话笔记。将记忆分成两个系统使检索变得清晰得多。

第一个是经验（lessons）：智能体在工作中学到的东西。错误、纠正、模式、首选方法。这些存储在git跟踪的JSONL中，在SQLite中建立索引，通过语义相似性和关键词搜索的混合进行检索。新会话在编写任何代码之前就会拉入相关的经验。

项目中自身开发的一个真实经验条目：

```
{
  "id": "L821b491a",
  "type": "lesson",
  "insight": "Inlining phase instructions in a workflow orchestrator causes context drift under compaction. Delegate each phase to its own slash command so instructions are re-injected fresh.",
  "tags": ["compaction", "workflow", "architecture"],
  "severity": "high"
}

```

第二个是知识（knowledge）。我将它指向文档文件夹（规范、架构决策、研究论文），它会对所有内容进行分块、嵌入和索引。当智能体需要关于系统如何设计或为什么做出某个决策的上下文时，它查询知识库而不是从代码中猜测。

一个知识块看起来像这样：

```
{
  "filePath": "docs/ARCHITECTURE-V2.md",
  "text": "The three layers are not independent: memory without feedback loops is unreliable. Feedback without navigable structure fires blindly.",
  "contentHash": "a4f2e8..."
}

```

两者都使用语义相似性和关键词匹配的混合方式进行索引，这意味着检索既快又相关。经验作为代码库的便签簿，就像我放在桌上的个人笔记本。知识作为可查询的图书馆。它们共同为每个新会话提供了真正的起点，而不是空白页面。

### 2.2 工作流和编排

在这两层之上是工作流。我早期发现将所有阶段指令塞入一个提示会导致上下文漂移。随着对话增长，智能体会逐渐丢失早期指令的追踪。因此每个阶段作为自己的slash命令运行，每次重新注入新指令。五个阶段：

- **Spec Dev（规范开发）**：通过对话开发明确的需求。
- **Plan（规划）**：构建通过记忆搜索丰富的技术计划。
- **Work（执行）**：以测试驱动开发执行计划。
- **Review（审查）**：对变更运行专门的验证。
- **Compound（复合）**：提取学到的东西并写回到经验中，或通过lint提出更强的自动验证。

这些阶段可以手动运行，但重点是链式执行。最简单的方法是 `/compound:cook-it`，它在一个命令中运行所有五个阶段。

对于多个任务，`ca loop` 生成一个脚本，按依赖顺序拾取它们，并在各自的新会话中运行每个任务经过完整循环。如果一个失败，它会重试。如果审查发现问题，它们会被反馈给执行者。循环持续运行，直到所有任务关闭或需要人类输入。

重要的是，这是普通代码编排智能体，而不是AI编排其他AI。生成的脚本控制流程，决定接下来运行什么，处理重试和失败。智能体只在明确定义的边界内执行。这就是使其在实践中更可靠的原因：编排是确定性的，每个会话是独立的。

### 2.3 验证和钩子

我不信任任何模型的第一次通过。这是所有这些工作流背后的核心假设。系统在每个变更上运行多个专门的审查器，并且可以跨不同提供商的不同模型检查结果。一个模型遗漏的发现会被另一个捕获。重点不是为了流程本身而流程。重点是强制一个干净的循环，每个周期都让代码仓库为下一个周期处于更好的状态。

将所有这些联系在一起的是一组自动钩子，接入智能体的生命周期。会话开始时加载相关经验。会话结束时标记未捕获的经验。智能体不需要记住做这些。代码仓库来处理。

## 3、实际效果如何

我使用 `compound-agent` 构建了 `drift-watch`，一个独立的工具，用于跨会话跟踪AI智能体的行为漂移。

其背后的想法很简单：我越让自主工具为我构建，我就越无法自己看到行为漂移。除此之外，测试和lint模型在历史上是围绕人类行为设计的。智能体AI是不同的风格，我发现持续观察模型随时间的行为对于捕获新出现的但可能有害的模式至关重要。

在构建第二个插件时，有用的部分不是"一个命令就交付了整个产品"。有用的部分是工作从头到尾保持可读性。架构师将项目分解为适合单个工作周期的任务。`ca loop` 按依赖顺序运行它们，每个在自己的会话中。整个构建跨越多个会话，它们之间没有共享上下文。

循环沿途发现了真正的问题。审查发现了事件管道中缺失的错误处理、两个模块之间的数据库迁移差距，以及会话解析器上薄弱的测试覆盖率。我在简短的第二次运行中修复了这些。

这次构建相当自主。我实际上不在，只在所有验证关卡通过后回来看了一下。对我来说，这不是盲目的信任。我为工作以这种方式构建了越来越多的系统，我知道保持每个会话聚焦的原子任务设计、强规范和在问题复合之前捕获问题的审查层，是使我未监督的数小时构建最终得到一个可工作的、经过审查的代码库的原因。

这是系统今天的诚实状态。它已经对将规范转化为结构化的实现工作和在早期暴露缺陷很有用。它不决定构建什么，我也确实认为长时间自主运行还没有完全解决。我仍在优化它。

## 4、我现在在做什么

当前的瓶颈不是代码生成。而是系统规范和结果的强评估。我目前正在循环内实现更强的架构准备和基于场景的测试。

想法是在接受候选变更之前对其运行代表性场景，并拒绝不能改善结果的变更。困难的部分是定义足够精确以捕获回归但足够通用以经受多次迭代的场景。我认为同样的框架可以推广到编码之外的其他知识工作流程，但这是另一篇文章的主题。

## 5、入门

如果你想尝试 `compound-agent`，当前的入口是npm包：

```
pnpm add -D compound-agent
npx ca setup

```

它需要Node.js 20+，并安装本地记忆栈，包括嵌入模型。任务编排依赖于 [Beads](https://github.com/steveyegge/beads?ref=hubwiz.com)，因此代码仓库中也需要有 `bd` 可用。该工具正在积极开发中。

设置完成后，最佳起点是 `/compound:spec-dev` 或 `/compound:architect`。选择一个你想构建的项目，开始与Claude迭代定义范围、需求和任务分解。这就是系统开始发挥价值的地方。

目前最深的集成是与Claude Code，不过我正在推动与其他智能体CLI的集成。代码和架构文档位于 [NathanDela/compound-agent](https://github.com/NathanDela/compound-agent?ref=hubwiz.com)。

该项目由智能体AI构建，所以不要犹豫使用智能体来探索它。

---

原文链接: [How I Built an Open-Source Harness for Longer AI Coding Sessions](https://nathan-delacretaz.com/thinks/compound-agent-harness?ref=hubwiz.com)

汇智网翻译整理，转载请标明出处

> **这是「Agent / MCP」专题的一部分。**完整地图见：[Agent / MCP / 自动化完全指南](https://www.hubwiz.com/blog/agent-stack/)