--- title: Compound Engineering 重构：把 Agent 收进 Skill canonical: "https://xiaofeng.dev/en/writing/compound-engineering-agent-skill/" pubDate: 2026-06-30 author: 唐小锋 Xiaofeng TANG description: 大重构：把 Agent 收进 Skill 版本号也许看不出来，但这次对 Compound Engineering 来说是一次很大的更新。现在架构变了，文档组织方式变了，智能体能跑得更 tags: [Compound Engineering, Agent Skills] --- # 大重构：把 Agent 收进 Skill 版本号也许看不出来，但这次对 Compound Engineering 来说是一次很大的更新。现在架构变了，文档组织方式变了，智能体能跑得更久、也跑得更好，而且我们已经全面拥抱 `/goal`。 ## 我们杀掉了自己的智能体（有意为之） 这可能是 Compound Engineering 首次发布以来最大的一次结构性变化。 过去，Compound Engineering 依赖一组专门的独立智能体定义。它们在 Claude Code 里表现很好。但到了 Codex、Cursor、Gemini、Pi 和 OpenCode 里，效果就没那么稳定，甚至根本不能工作。原因是正式的智能体定义并不是各个运行环境都可靠支持的共同基础。每个运行环境处理智能体的方式都有些不同。 这意味着，我们要么维护多套针对不同运行环境的副本，要么让用户使用一个只能部分工作的版本，而且还需要通过额外的手动更新来保持最新。 我们把这一切都移除了，基本上是把东西拆到了最底层。 现在每个技能都是自包含的。我们仍然能实现专门的“智能体”行为，但所有内容都放在技能自己的提示词资产里，而不是放在正式的智能体定义里。它非常详细，可能细得有点过头，但它对现有用户和新用户都会产生很大影响。 不需要复制脚本。不需要嵌套路径。也不再有“更新之后还要重新跑 setup”。 实际效果是： - **Codex CLI 和 Codex 桌面应用**：现在可以干净地工作，包括作为一个支持自动更新的完整插件。之前 Codex 桌面应用还需要一些变通方案。 - **OpenCode、Pi 和 Cursor**：原生支持好了很多。插件现在只由技能组成，这意味着它也能放进那些根本没有“独立智能体”概念的插件系统里。 ## 计划现在已经为 `/goal` 准备好了 我们过去会产出两个文档：一个需求文档和一个实施计划。这其实是我们那套有缺陷的“全靠人类工作者”模式留下来的痕迹。 它们服务于工作流的不同阶段，从概念上说得通。但实际问题是，需求会随着实施过程不断变化。一旦变化，你就有两个文档要更新；它们可能彼此漂移；你得记住某个问题上哪个文档才是权威；智能体也必须把两个文档都放进上下文里，并在两者之间做协调。 新的统一“计划”文档把两者合并成一个产物。运行 `/ce-brainstorm` 时，它会先列出场景和需求。如果你接着运行 `/ce-plan`，这个文档会继续更新，把实施计划细节也纳入其中。这样你和你的智能体就拥有一个完整的文档包。 更重要的变化在于这个文档的设计目标。它已经为 `/goal` 准备好了：它有清晰的完成定义，范围是收敛的，实施方式也足够明确，让智能体可以基于它工作，而不需要不断回来确认。 在 `/ce-plan` 的末尾，我们会提供一个选项，直接把这个计划交给 `/goal` 启动。然后你就可以走开了，或者切换到另一个智能体去做另一组工作。智能体知道“完成”到底长什么样，因为这已经写在文档里了。 在复杂功能的测试中，这个循环表现得很好。我跑过几次持续数小时的完整功能开发，其中一次超过了 6 小时。智能体完整实现了功能，写了测试，打开了 PR，并且在初始计划交接之后，没有任何人介入就完成了交付。 对于带界面的功能，在智能体完成第一轮工作之后，你还有空间审阅、迭代和调整，这也是 `/ce-polish` 这类技能能发挥作用的地方。 可移植性也是额外收益：一个文档更容易在多个智能体之间传递，附到任务上，或者放进新的上下文里。 ## 需要画图时，文档也会画图 计划和想法并不总是适合写成一整墙文字。有些东西就是需要图。 所以现在技能支持把真正的 HTML 输出作为一个选项。使用它时，文档会在文字之外补充视觉内容：在图比段落更能说明问题的地方放上图。 `ce-ideate` 更进一步，默认输出 HTML，因为构思本来就是一个需要人参与的时刻，而人阅读草图式想法的速度，比读规格文档更快。统一的计划文档也支持同样的处理方式。 关于如何使用，有几点需要知道： - **Markdown 仍然是默认格式。** 大多数 Compound Engineering 用法，包括我们自己的用法，都是把文档直接交给智能体，而 Markdown 是更合适的选择。HTML 是可选项。 - **一行就能试。** 下次运行 `ce-brainstorm` 或 `ce-plan` 时，加上 `output=html` 或 `use html format`。 - **设置一次，以后不用再管。** 把你偏好的默认格式放进 `AGENTS.md` / `CLAUDE.md`，或者放进你的 Compound Engineering 配置，这样就不必每次提示都重复输入。 - **它会尊重你的品味。** 如果你的仓库根目录有 `DESIGN.md`，技能会用它来影响文档设计，同时保持内容清晰可读。 对大多数用户来说，包括我们自己，Markdown 仍然是默认格式。大多数时候，文档会直接交给智能体，而智能体不需要 HTML。视觉路径是为那些人类会阅读、而内容又确实受益于视觉表达的场景准备的。 ## 还有几件事 - **跨模型对抗式审查。**`ce-code-review` 增加了跨模型对抗式审查：让第二个模型主动尝试找出第一个模型工作中的问题。我们也把审查范围调到了合适大小，并通过一条可移植路径来处理它，让它在各处表现一致。 - **更聪明的 PR 反馈处理。**`ce-resolve-pr-feedback` 现在会先集中判断问题，再分派修复任务，而不是并行发出修复请求然后碰运气。 - **ce-brainstorm 有了眼睛。** 头脑风暴期间现在有视觉反馈，而不只是文本变化。当讨论需要时，智能体会启动一个小的视觉产物来获取你的输入，并在一个小型网页服务里预览；等你完成后，再把会话关掉。即使在 Codex 应用里也能工作。 - **插件市场和安装流程全面修复。** 插件和市场元数据已经对齐，技能描述减少了 50%，在 Pi 和 OpenCode 等更多运行环境上，安装更容易也更快。 ## 如何获取 这个版本包含插件市场更新，这意味着你的运行环境常规更新机制可能不足以拿到它。对现有安装来说，最稳妥的方式是移除插件，然后从插件市场重新安装一遍。 这有点麻烦，但这是能保证你拿到正确版本和正确插件数据的方式。我们也修复了一些插件市场和插件数据问题，这些问题之前给首次安装造成了摩擦，所以现在流程应该会比以前更顺。 重新安装：从你的运行环境中移除 Compound Engineering，然后按照仓库说明里的安装步骤操作。不同运行环境的安装方式不同，所以仓库说明才是针对你具体设置的正确参考。 如果你是新用户：安装后在任意项目里运行 `ce-setup`，它会帮你开始。为 `/goal` 准备好的计划文档和 HTML 输出都可以马上试。 ## 为什么这次重要 大多数版本都是在增加东西，但这一次感觉要大得多。更新你的插件。拿一个真实问题跑 `/ce-brainstorm`。告诉我们效果如何。 Trevin Chow：专注于 AI 和 AI 构建实践。参与开源项目，包括 @ppressdev、@illo_skill 和 Compound Engineering。