7.0
热点
AI SCORE
技术实践2026-08-01 07:20
三大 AI 工程框架对比：任务级 vs 轨迹级的设计分歧
dev.to · AI#AI工程#框架
Editor brief · 编辑速览
对 Trellis、OpenSpec、AGE 三个框架的设计理念进行对比，帮助开发者选择适合的工程范式。
对 Trellis、OpenSpec、AGE 三个框架的设计理念进行对比，帮助开发者选择适合的工程范式。
Trellis 是一个第三方开源模板（@mindfoldhq/trellis），旨在“为 14 种以上平台上的 AI 编码智能体提供一致的工程工作流”。
OpenSpec 是一个类似的第三方开源框架（@fission-ai/openspec），专注于“规范驱动开发”，并通过增量规范管理变更。
AGE（Attractor-Guided Engineering，吸引子引导工程）是一套源自 nop-chaos-flux 实践的方法论，其核心思想是：状态空间 → 吸引子 → 轨迹 → 控制。微信公众号系列文章：《驾驭之前先谈吸引子：大规模 AI 开发方法论》《从规范驱动开发到吸引子引导工程》《为什么吸引子引导工程不能被降级为一种 AI 智能体技能》《控制层与方向层的分野：OpenProse、NLAHs 与 AGE》
微信公众号系列文章：
《驾驭之前先谈吸引子：大规模 AI 开发方法论》
《从规范驱动开发到吸引子引导工程》
《为什么吸引子引导工程不能被降级为一种 AI 智能体技能》
《控制层与方向层的分野：OpenProse、NLAHs 与 AGE》
AGE 并不预设大量固定工具；它强调，工具应当从反复出现故障的地方逐步涌现：重复错误 → Bug 记录 → 经验教训 → 技能/提示词 → 审计脚本 → lint 规则 → CI 护栏。
核心发现：Trellis 和 OpenSpec 的共同局限在于，两者都以单次变更作为组织单元，缺乏仓库级事实来源，也缺乏向全面 AI 自动化演进所需的支撑能力。本文从 AGE 的理论框架出发，比较三者之间的根本差异。
一种产品化的工程框架，通过 npm install -g @mindfoldhq/trellis && trellis init 安装。
提供三阶段工作流（Plan → Execute → Finish）、任务管理脚本、规范系统、子智能体调度以及多平台钩子。
工具链在设计阶段就已确定：包含 trellis-brainstorm、trellis-check、trellis-update-spec、trellis-break-loop 等 12 项技能。
五项核心原则：编码前先规划、规范通过注入而非记忆提供、持久化一切、增量开发、沉淀经验。
一种产品化的规范驱动框架，通过 npm install -g @fission-ai/openspec && openspec init 安装。
核心模型是 spec + delta + archive 循环：specs/（事实来源）← 合并 ← changes/（增量规范）。
每次变更包含四类产物——proposal → specs → design → tasks——并按照模式依赖图生成。
增量规范使用 ADDED/MODIFIED/REMOVED 描述增量修改，并在归档时合并回主规范。
四项理念：灵活而非僵化、迭代而非瀑布式、简单而非复杂、棕地优先。
支持与 25 种以上 AI 工具进行斜杠命令集成。
一种方法论，而非产品。没有 npm 包，也没有安装命令。
AGE Template 是一套复制即用的文档骨架（https://github.com/entropy-cloud/attractor-guided-engineering-template），用于定义文档职责和流程，并附带通用工具（check-doc-links、check-oversized-files 等）。特定领域的工具需要从实践中提炼。
AGE 作者开源了多个大型示例项目，展示不同领域中完整的 AGE 实践：nop-chaos-flux（https://github.com/entropy-cloud/nop-chaos-flux）：一个前端低代码框架，包含 15 个审计文件（其中 11 个为扫描器）、22 个提示词、66 条 Bug 记录和 72 份日志。nop-entropy（https://github.com/entropy-cloud/nop-entropy）：一个后端全栈框架，包含 docs-for-ai/ 规范性文档和 ai-dev/ 开发记忆轨迹。nop-chaos-next（https://gitee.com/canonical-entropy/nop-chaos-next）：一个应用层项目，以 design/、input/、logs/、skills/ 进行轻量级实践。
nop-chaos-flux（https://github.com/entropy-cloud/nop-chaos-flux）：一个前端低代码框架，包含 15 个审计文件（其中 11 个为扫描器）、22 个提示词、66 条 Bug 记录和 72 份日志。
nop-entropy（https://github.com/entropy-cloud/nop-entropy）：一个后端全栈框架，包含 docs-for-ai/ 规范性文档和 ai-dev/ 开发记忆轨迹。
nop-chaos-next（https://gitee.com/canonical-entropy/nop-chaos-next）：一个应用层项目，以 design/、input/、logs/、skills/ 进行轻量级实践。
理论框架：状态空间 → 吸引子 → 轨迹 → 控制；所有实践要素都可以从中推导出来。
Trellis 内置了 12 项技能；AGE 的领域工具需要自行积累，或从其他项目借鉴。
Trellis 的 12 项技能在项目创建时便已存在：
这些技能具有通用性，与任何具体项目无关。用户不需要先积累 Bug 历史或审计发现，就能获得这些工具。其中，trellis-break-loop 和 trellis-update-spec 构成了从故障中提炼知识的机制（详见第 3 节）。
nop-chaos-flux 中的工具成长链清晰可见：
链路 1：硬编码类型分派 → 审计脚本
发现 Bug：渲染器中存在硬编码的类型 switch
→ 审计发现：违反“渲染器应通过注册表进行分派”的架构契约
→ 计划 430：eliminate-hardcoded-type-dispatch-plan
→ 提炼为脚本：scripts/audit/find-hardcoded-type-dispatch.mjs
→ 规则编码于：scripts/audit/rules.mjs
链路 2：缺少渲染器标记 → 审计脚本
发现 Bug：渲染器未按照契约输出标记类
→ 在深度审计维度 09 中多次出现
→ 提炼为脚本：scripts/audit/find-missing-renderer-markers.mjs
链路 3～5：不精确的响应式订阅、没有失败路径的异步操作、React 19 遗留 API → 每项都有对应的审计脚本。
nop-entropy 也遵循相同模式：
发现 Bug：Java 代码中使用了裸 RuntimeException
→ 约定：应使用 NopException 的子类
→ 提炼为 ast-grep 规则：ai-dev/tools/rules/java-lint-bare-runtimeexception.yml
新的 Trellis 项目可以立即获得完整的 12 项技能、工作流状态机和跨平台钩子。基于 Template 启动的新 AGE 项目最初只有通用工具，但可以参考 nop-chaos-flux、nop-entropy 和 nop-chaos-next 等开源范例，快速建立领域专用工具。Trellis 适合“今天就开始”；AGE 适合“长期演进”。
Trellis 和 AGE 都会从故障中提炼知识，但产物形式和自动化程度有所不同。
trellis-break-loop 提供了一个结构化的五维 Bug 分析框架：
根本原因类别：五类（规范缺失 / 跨层契约 / 变更传播失败 / 测试覆盖缺口 / 隐含假设）
修复失败的原因：四种失败模式（表面修复 / 范围不完整 / 工具限制 / 心智模型）
预防机制：六种机制（文档 / 架构 / 编译时 / 运行时 / 测试覆盖 / 代码审查）
系统性扩展：类似问题 / 设计缺陷 / 流程缺陷
知识沉淀：强制更新规范文件（“如果分析只停留在聊天中，它就毫无价值。真正的价值在于更新后的规范。”）
分析完成后，知识会通过 trellis-update-spec 写入 .trellis/spec/，并沉淀为 Design Decision、Common Mistake、Case Study 等形式的文字内容。
AGE 的晋级阶梯（AGE Template AGENTS.md 规则 15）：
第 0 级：发现重复出现的问题
↓
第 1 级：Bug 记录（docs/bugs/）——记录不明显的根本原因
↓
第 2 级：经验教训（docs/lessons/）——提炼可复用的判断规则
↓
第 3 级：技能/提示词（docs/skills/）——可复用的审计/诊断方法
↓
第 4 级：审计脚本（scripts/audit/）——半自动扫描
↓
第 5 级：lint 规则 / CI 护栏——全自动拦截
nop-chaos-flux 的 docs/skills/ 目录（22 个提示词文件）：
两者都会从故障中提炼知识，但产物的形式和自动化级别不同：
AGE 之所以能够逐级晋升，是因为它设置了专门的时效性文档类别（bugs/、lessons/、skills/），用于追踪某种模式是否重复出现。Trellis 只会将知识一次性沉淀到规范中；当相同错误再次出现时，并不存在升级路径。
这是两个紧密交织的维度：由谁决定文档结构，以及规范性信息与历史信息是否分离。
.trellis/ # Trellis 规定的顶层目录
├── spec/ # 按包/分层组织的编码约定 + 积累的经验
│ ├── cli/backend/
│ ├── cli/unit-test/
│ └── guides/
├── tasks/ # 以日期命名的任务目录（完成后归档）
│ └── MM-DD-name/
│ ├── prd.md / implement.jsonl / check.jsonl / task.json
└── workspace/ # 按开发者姓名隔离的会话记忆（达到 2000 行时轮换）
这一结构服务于 Trellis 自身的运行：spec/ 的分层服务于 get_context.py 的发现机制，tasks/ 的格式服务于 task.py 的生命周期管理，而 workspace/ 按开发者隔离则服务于多用户场景。5 项核心原则（编码前先规划、持久化一切等）是跨项目约束。
规范性内容与历史性内容并未分离。trellis-update-spec 的模板类型（Design Decision、Common Mistake、Case Study、Gotcha）天然鼓励将历史信息写入规范。trellis-break-loop 也要求在完成 5 维分析后“更新 spec/guides”。Trellis 没有独立的 bugs/、logs/ 或 lessons/ 目录——tasks/ 会在完成后归档，而 workspace/journal 达到 2000 行时便会轮换。经验教训除了进入规范之外，无处可去。
一个真实示例——quality-guidelines.md（982 行）中的历史性内容：
“案例研究（2026-04-22）：4 个写入方 + 类型声明之间的 current_phase / next_action 漂移”——一段完整的 Bug 演变历史，包括“第一次审计遗漏了什么”“四种漂移模式”和“最终集成结果”
“警示案例——0.6.0-beta.3 → 0.6.0-beta.4 紧急回滚”——一次版本回滚事故的记录
“案例研究（2026-04-30）：issue #204 --yes + bootstrap 恢复”——包含 commit hash、发现过程和修复过程
在 workflow-state-contract.md（299 行）中：“两个生产环境 Bug（Phase 1.3 jsonl 整理跳过、Phase 3.4 commit 跳过）恰好触发了这一故障模式。”
将案例研究混入规范，可以直接提供因果上下文（“这条规则为什么存在”）；而在 AGE 中，要获得同样的上下文则需要跨文件引用。代价是规范文件不断膨胀，而且 AI 在阅读时无法区分“当前规范”和“历史经验”。
AGE 的文档组织只有两项约束：
渐进式披露：从最小入口（index / start-here）开始，逐步展开到详细内容。
分离规范性内容与时间敏感的历史记录：稳定文件使用稳定的名称；时间敏感的记录带有日期。
在这些约束之内，每个项目根据自身领域需求组织文档结构。
nop-chaos-flux（前端低代码框架）：docs/architecture/ 按 4 层优先级组织（programme → conventions → baseline → subsystems），docs/components/ 中有 100 份组件设计文档，docs/references/ 将最常用的类型压缩到单个文件中。这是前端框架的领域需求。
nop-entropy（后端全栈框架）：docs-for-ai/ 按带数字前缀的阅读顺序组织（00→04），并与 ai-dev/（开发过程记忆）分离。因为用户和开发者是完全不同的受众。
AGE Template（应用层项目）：将 input/（PM 原始输入）与 requirements/（可直接实施的需求）分离，并设有 backlog/（优先级队列）。这是应用开发的领域需求。
AGE 对规范性内容与历史性内容的分离，在 nop-chaos-flux 规划指南的规则 14 中有明确规定：
docs/architecture/ 下的文档只描述最新的当前设计状态。不要写历史变更，不要写“Proposed vs Current”比较，不要写演变叙事。
规范性文档中只允许出现三类与历史相关的内容：作出某项选择的原因（为什么选择 A 而不是 B）、被否决的备选方案及其原因（负空间），以及例外记录（“有意保留的遗留行为”）。演变叙事必须留在 logs/、bugs/、plans/ 中。
AGE 规划并不是“把这件事做完”，而是为 AI 的完全自主执行建立可验证的闭环条件。
AGE 规划有三个关键关卡，全部由独立的 AI 子智能体完成：
草案审查：由独立子智能体审计范围是否如实、闭环关卡是否真实存在，以及是否存在隐藏依赖。
执行：AI 围绕规划执行，在每一步记录聚焦证明、所有者文档同步情况以及验证结果。
闭环审计：另一个独立子智能体回到实时仓库中重新检查——独立验证代码、文档、测试，以及闭环条件是否真正得到满足。
nop-chaos-flux 的规划指南（403 行，24 条最小规则）明确要求：
规则 8：“completed 必须来自一次独立的闭环审计”
规则 12：“在标记为 completed 之前，必须完成由独立审查者或独立子智能体执行的闭环审计”
规则 11：“关闭规划时，必须区分‘契约表面已经出现’与‘契约语义已经落地’”
AGE 的总体目标是逐步减少人工干预节点。在当前实践中，人类仍然控制少数关键节点（定义吸引子、仲裁冲突、校准方向），但规划的草案审查和闭环审计已经完全由独立的 AI 子智能体完成。未来方向是：人类只控制输入和最终输出，并通过抽样方式监控中间过程。
first-principles-of-agent-engineering.md 对智能体本质的定义是：“智能体是一种在目标约束下，跨时间维护、验证、修正和复用可行动认知结构的系统。”规划是验证与修正的局部载体——它定义“这一轮扩展真正完成究竟意味着什么”，随后由独立子智能体进行验证。
Trellis 的规划/执行系统分为两层：
第一层：PRD（设计文档 + 需求文档）。Trellis 的 prd.md 与其说是纯需求文档，不如说更接近设计文档——其中包含 Goal、Assumptions、Requirements、Acceptance Criteria、Out of Scope、Decisions（轻量 ADR）以及 Technical Notes。它在 Phase 1 中通过与用户协作式头脑风暴共同创建。
第二层：通用执行流程。workflow.md 为每项任务定义了一套通用的三阶段执行列表：Phase 1（1.0–1.5：创建任务 → 探索需求 → 调研 → 配置上下文 → 激活）→ Phase 2（2.1–2.3：实现 → 质量检查 → 回滚）→ Phase 3（3.1–3.5：质量验证 → 调试复盘 → 更新规范 → 提交 → 收尾）。Phase 2 的实现和检查由子智能体自主完成；Phase 3.4 的提交需要用户进行一次性确认。
AGE 规划与 Trellis 的 PRD + 执行流程对比：
AGE 的 AGENTS.md 强制要求：“完成任何重大代码变更后，你必须更新当日开发日志。”
nop-chaos-flux 的 docs/logs/2026/ 目录包含 72 个每日日志文件，每个文件都会记录：具体关闭了哪项规划中的哪条工作流、修改了哪些代码路径（精确到 file:line）、通过了哪些聚焦证明、同步更新了哪些所有者文档、全仓库验证状态，以及执行独立闭环审计的子智能体任务 ID。
Trellis 中对应的是 workspace/journal-N.md——个人会话记忆，达到 2000 行后轮换。它不记录精确的代码路径和验证基线，也与规划没有关联。
AGE 和 Trellis 都设有代码质量关卡。区别在于 AGE 额外增加了一层方向性审计。
Trellis 的 Phase 2.2（Quality check）和 Phase 3.1（Quality verification）要求运行 pnpm lint && pnpm typecheck && pnpm test，并由 trellis-check 技能封装。
AGE 同样设有强制关卡。nop-chaos-flux 的规划指南要求 pnpm typecheck/build/lint/test 全部通过后才能关闭规划；nop-entropy 的 AGENTS.md 要求 ./mvnw test -pl <affected-module> -am 通过，而规则 13 明确指出：“已经进入 lint、静态检查脚本或 CI fail-fast 的固定规则，是不可协商的硬约束。”nop-entropy 的 pre-commit hook 也会强制执行代码格式检查。在这一层面上，两者是等价的。
trellis-break-loop 提供结构化的 Bug 复盘（Root Cause Category / Why Fixes Failed / Prevention / Systematic Expansion / Knowledge Capture），并在分析完成后更新规范。
Deep Audit（deep-audit-prompts.md，2141 行，20 个维度）涵盖 6 个类别：
第 16–18 个维度专门审计文档与代码之间的一致性。审计执行模型：阶段 1 为迭代式深挖（每个维度最多 10 轮，每轮由独立的子智能体执行）；阶段 2 为独立复核（由独立的子智能体返回实际代码，重新确认每一项发现）。
开放式对抗审查（open-ended-adversarial-review-prompt.md）不预设检查维度，鼓励蛙跳式探索与自我否定，并持续循环，直到不再出现新的发现。
AGE 增加了方向性审计：所有者文档是否与代码一致、命名是否与术语表一致、同一概念在不同包中是否以一致的方式实现。深度审计的执行成本极高（需要多轮独立子智能体参与）——这是必须权衡的取舍。
Trellis 和 OpenSpec 存在三个结构性缺陷。
Trellis 和 OpenSpec 的核心组织单元都是单次变更（一个任务／一项变更），而不是整个代码仓库。
Trellis：每个任务都有自己的 prd.md；spec/ 是一组层层堆叠的编码规范。它没有一个维护点，用于描述“整个系统当前是什么状态，以及它应当向什么方向收敛”。
OpenSpec：specs/ 声称自己是事实来源，但它实际上是需求的累积（每次归档都会合并增量，只增加、从不移除），而不是方向定义。不断累积的规格是一份需求列表，而不是架构吸引子。
AGE 的所有者文档维护整体方向：哪些模块必须分离、依赖只能沿哪个唯一方向流动，以及哪些概念绝不能混合在一起。
AGE 的 first-principles-of-agent-engineering.md 区分了两类事实来源：四维事实（事实、因果来源、置信状态、负空间）回答“现在是什么、过去是什么”，而吸引子回答“它应当向什么方向收敛”。Trellis 和 OpenSpec 并未区分这两类来源——它们只有“当前规格”（specs/spec），没有“方向定义”（attractor）。
Trellis：任务完成后即被归档；journal 超过 2000 行后会轮换。下一个任务无法看到上一个任务做了什么、为什么做出那些决策，以及哪些方案曾被否决。
OpenSpec：变更在归档后会保留于 archive/ 中，但它们只是历史文件夹。这里没有结构化的轨迹记录（代码路径、验证基线、所有者文档同步状态）。下一次变更无法从上一次变更的执行过程中学习。
AGE 的 logs/ 是强制记录的轨迹：精确到代码路径、聚焦式证明、所有者文档同步情况和验证基线。bugs/ 记录负空间（排除了哪些路径、证伪了哪些假设）。未来的会话可以根据轨迹恢复“截至昨天发生了什么”。
这种差异源于组织单元的不同：任务级工具关心“这次变更是否正确”，而代码仓库级方法论关心“经过 AI 连续多次修改后，代码仓库是否仍在朝正确的方向前进”。
Trellis：人类参与 PRD 协作与提交确认；其三阶段流程是为人类设计的。它没有独立的闭环审计；最终检查由人类完成。
OpenSpec：/opsx:propose 和 /opsx:verify 都假设有人类参与其中。verify 是可选的，也没有独立验证。tasks.md 是供人类阅读的检查清单。
AGE 的计划草案审查与闭环审计由独立的 AI 子智能体完成；人类逐步退出。计划是一份闭环契约，而不是供人类使用的任务列表。吸引子定义“向哪里收敛”，审计检查“我们是否正在收敛”——两者都不需要人类干预。
AGE 的 age-from-state-engineering-to-trajectory-engineering.md 直截了当地指出：传统软件工程的基本结构是“状态检查＋人类隐性的方向感”。当 AI 深度参与后，人脑不再掌握完整蓝图；这种“方向感”必须被外化到代码仓库结构中。Trellis 和 OpenSpec 仍然依赖人类隐性的方向感——它们让单次 AI 与人类的协作更加可靠，但无法取代人类对方向的判断。
相较于彼此，两者都取得了一些进展，但仍然局限在任务级框架之内。
Trellis 相较于 OpenSpec 的进步：
从失败中提取知识并回写到 spec：trellis-break-loop（五维缺陷分析）→ trellis-update-spec（强制更新 spec 文件）。OpenSpec 的 /opsx:archive 只会合并增量规格（需求变更），不会回写失败教训——学到的经验会停留在归档文件夹中，无法回流到 specs。
完整的执行流水线：子智能体调度（trellis-implement/trellis-check）、jsonl 上下文注入、回滚。OpenSpec 只有产物依赖图（proposal → specs → design → tasks），没有执行流程管理——/opsx:apply 依赖 AI 自行查找并读取规格。
结构化缺陷分析：trellis-break-loop 的五维分析框架（Root Cause Category / Why Fixes Failed / Prevention / Systematic Expansion / Knowledge Capture）。OpenSpec 没有对应机制。
OpenSpec 相较于 Trellis 的进步：
强制规格验证：openspec validate 使用 Zod schema 解析 Markdown，强制要求包含 Purpose 部分、Requirements 部分、每项 Requirement 至少包含一个 Scenario、ADDED/MODIFIED 必须包含 SHALL/MUST，并且不同部分之间不得存在冲突。Trellis 的 spec 文件完全是自由格式的 Markdown，没有结构验证。
增量机制：使用 ADDED/MODIFIED/REMOVED 描述增量变更，并在归档时进行合并。它比 Trellis“把所有知识都塞进 spec 文件”的方式更具结构性。
规格／变更分离：specs/（事实来源）与 changes/（增量修改）彼此分离。相比 Trellis 不区分规格与提案的做法，这更进一步。
OpenSpec 的规格格式存在一个根本局限：Given/When/Then Scenario 是一种面向机器验证的格式（可以自动转换为测试用例），而不是供人类阅读的方向定义。AGE 的所有者文档则是供人类阅读的架构方向（“模块必须分离”“依赖只能单向流动”）；两者面向的受众不同。
动力系统思想（状态空间 → 吸引子 → 轨迹 → 控制）是 AGE 最早确立的概念框架。但具体实现——所有者文档采用什么结构 u