Trellis vs OpenSpec vs AGE：任务工具与轨迹方法论对比
简介
先说几个核心判断。今天我们来聊三个在AI编码领域逐渐形成影响力的思路——Trellis、OpenSpec和AGE。很多人会问，它们都是干嘛的？为什么放在一起比？它们之间到底差在哪？
- Trellis 是一个第三方开源模板（
@mindfoldhq/trellis），目标很明确：让AI编码流程在14+平台上跑出一致的工程流程。 - OpenSpec 同样是第三方开源框架（
@fission-ai/openspec），核心打法是“spec-driven development”，通过delta specs来管理变更。 - AGE（Attractor-Guided Engineering） 则不一样——它是一个方法论，从nop-chaos-flux的实践中长出来，核心思想可以概括为：
状态空间 -> 吸引子 -> 轨迹 -> 控制。
必须搞清楚的一点是，AGE不预设固定的工具集，它信奉工具应该从反复出错的地方慢慢长出来——从频繁出现的错误到bug note，再到lesson、skill/prompt，最终落地为audit script、lint rule，甚至CI guard。这和前两者开箱即用的思路形成了鲜明反差。
那么，问题来了。Trellis和OpenSpec有一个共同的局限：它们都以单次变更为组织单元，缺少对仓库整体真相的把握，也缺乏向AI全自动演进的支撑能力。本文就从AGE的理论框架出发，把三者的根本差异掰开来看看。
分析
1. 定位：三者是什么
先把三个东西摆到桌面上，看看它们各自是什么、怎么用。
Trellis：
- 产品化的工程框架，一条
npm install -g @mindfoldhq/trellis && trellis init就能跑起来。 - 内置3相位工作流（Plan → Execute → Finish），还有任务管理脚本、spec系统、子袋里分派、跨平台hook等一整套东西。
- 工具链在设计阶段就锁死了：
trellis-brainstorm、trellis-check、trellis-update-spec、trellis-break-loop等12个skill全部预装。 - 遵循5条核心原则：Plan before code、Specs injected not remembered、Persist everything、Incremental development、Capture learnings。
OpenSpec：
- 产品化的spec-driven框架，同样
npm install -g @fission-ai/openspec && openspec init即用。 - 核心模型是一个循环：spec + delta + archive。
specs/是真相源头，通过merge吸收changes/（delta specs）的更新。 - 每个change包含proposal → specs → design → tasks四种产物，按schema依赖图生成。
- Delta specs用ADDED/MODIFIED/REMOVED描述增量修改，archive时合并回主spec。
- 4条哲学：fluid not rigid、iterative not waterfall、easy not complex、brownfield-first。
- 支持25+AI工具的slash command集成。
AGE：
- 一个方法论，不是产品。没有npm包，没有安装命令。
- AGE Template是一个复制即用的文档骨架，定义了文档职责和流程，附带一些通用工具（如
check-doc-links、check-oversized-files）。领域特定的工具需要从实践中自己长出来。 - AGE作者开源了多个大型范例项目，展示AGE在不同领域的完整实践：
- nop-chaos-flux：前端低代码框架，15个审计文件（含11个扫描器）、22个prompt、66个bug note、72个日志。
- nop-entropy：后端全栈框架，
docs-for-ai/规范文档 +ai-dev/开发记忆分轨。 - nop-chaos-next：应用层项目，
design/、input/、logs/、skills/轻量实践。
- 理论框架清晰：
state space → attractor → trajectory → control，所有实践元素都可以从这个框架推导出来。
2. 工具来源：预设 vs 逐步生长出来
工具是怎么来的？这是个很有意思的分野。Trellis内置了12个skill，而AGE的领域工具需要自己慢慢积累，或者从别处借鉴。
Trellis：工具在设计时就确定了
Trellis的12个skill在项目创建的一瞬间就存在了，它们和具体的项目没有任何关系：
| Skill | 来源 | 职责 |
|---|---|---|
trellis-brainstorm | 框架预设 | 需求发现流程 |
trellis-check | 框架预设 | 代码质量检查 |
trellis-update-spec | 框架预设 | spec回写 |
trellis-break-loop | 框架预设 | 深度bug分析（5维度框架） |
trellis-before-dev | 框架预设 | 开发前上下文加载 |
trellis-finish-work | 框架预设 | 任务收尾 |
trellis-start | 框架预设 | 任务启动 |
trellis-continue | 框架预设 | 任务恢复 |
trellis-meta | 框架预设 | 框架自身操作 |
first-principles-thinking | 框架预设 | 思维方法 |
python-design | 框架预设 | Python设计指南 |
contribute | 框架预设 | 贡献指南（文档、marketplace） |
这些skill是通用的、与具体项目无关的。你不需要有任何bug历史或审计发现，就能直接拿到它们。当然，其中trellis-break-loop和trellis-update-spec构成了一套从失败中提取知识的机制，这个后面再说。
AGE：工具从实践中逐步提炼
AGE偏偏不干这事。以nop-chaos-flux为例，它的工具生长链路清晰可见：
链路1：硬编码类型分发 → audit script
Bug发现：渲染器中存在硬编码的type switch
→ 审计发现：违反"渲染器应通过注册表分发"的架构契约
→ Plan 430: eliminate-hardcoded-type-dispatch-plan
→ 提取为脚本: scripts/audit/find-hardcoded-type-dispatch.mjs
→ 规则编码在: scripts/audit/rules.mjs链路2：渲染器marker缺失 → audit script
Bug发现：渲染器未按契约输出marker class
→ 多次出现在deep audit维度09
→ 提取为脚本: scripts/audit/find-missing-renderer-markers.mjs类似的链路还有3-5条，分别对应响应式订阅不精确、async无失败路径、React 19遗留API等问题，最终都变成了各自的audit script。
nop-entropy同样遵循这个模式：
Bug发现：Ja va代码中使用裸RuntimeException
→ 约定：应使用NopException子类
→ 提取为ast-grep规则: ai-dev/tools/rules/ja va-lint-bare-runtimeexception.yml开箱即用 vs 逐步积累
说白了，Trellis新项目一启动就是完整的12个skill加工作流状态机加跨平台hook；AGE新项目从Template起步，只有通用工具。不过AGE并不亏，你可以参考nop-chaos-flux、nop-entropy、nop-chaos-next这些开源范例，快速搭起自己的领域工具。Trellis适合“今天就要开始干”，AGE适合“我打算长期演着来”。
3. 从失败中提取知识：两种不同深度的机制
Trellis和AGE都重视从失败中学习，但产物的形式和自动化程度差了不止一个级别。
Trellis：提取到prose spec
trellis-break-loop提供了一个结构化的5维度bug分析框架：
- Root Cause Category：5类（Missing Spec / Cross-Layer Contract / Change Propagation Failure / Test Coverage Gap / Implicit Assumption）
- Why Fixes Failed：4种失败模式（Surface Fix / Incomplete Scope / Tool Limitation / Mental Model）
- Prevention Mechanisms：6种预防机制（Documentation / Architecture / Compile-time / Runtime / Test Coverage / Code Review）
- Systematic Expansion：相似问题 / 设计缺陷 / 流程缺陷
- Knowledge Capture：强制要求更新spec文件——“The analysis is worthless if it stays in chat. The value is in the updated specs.”
分析完成后，知识通过trellis-update-spec写入.trellis/spec/，以Design Decision、Common Mistake、Case Study等形式沉淀为纯文本。
AGE：提取到逐步自动化的工具
AGE的晋升阶梯（AGE Template AGENTS.md Rule 15）非常清晰：
Level 0: 发现重复问题
↓
Level 1: bug note (docs/bugs/) — 记录非显然根因
↓
Level 2: lesson (docs/lessons/) — 提取可复用的判断规则
↓
Level 3: skill/prompt (docs/skills/) — 可复用的审计/诊断方法
↓
Level 4: audit script (scripts/audit/) — 半自动化扫描
↓
Level 5: lint rule / CI guard — 全自动化拦截nop-chaos-flux的docs/skills/目录下躺着22个prompt文件，它们的来源很有意思：
| Skill/Prompt | 晋升来源 |
|---|---|
bug-diagnosis-prompt.md (242行) | 从66+ bug修复历史中提取的诊断方法论 |
open-ended-adversarial-review-prompt.md (116行) | 从多轮对抗性审查中提取的开放式发现方法 |
deep-audit-prompts.md (2141行，20维度) | 从多轮深度审计中提取的结构化审查框架 |
implementation-contract-review-prompt.md | 从plan闭合审计中提取的契约审查方法 |
核心差异
两者都从失败中提取知识，但产物形式和自动化程度完全不同：
| 维度 | Trellis | AGE |
|---|---|---|
| 分析框架 | 5维度（break-loop） | 晋升阶梯（5层级） |
| 知识产物 | prose spec（编码约定、案例） | prompt → script → lint rule（逐步自动化） |
| 沉淀位置 | .trellis/spec/ | docs/skills/ → scripts/audit/ → CI |
| 自动化程度 | prose only（人读） | prose → 半自动扫描 → 全自动拦截 |
| 递进机制 | 无（break-loop产出直接进spec） | 有（同一模式重复出现时晋升到更高层级） |
AGE之所以能递进，是因为它有专门的时效性文档类别（bugs/、lessons/、skills/）来跟踪模式是否重复出现。Trellis的知识是一次性沉淀到spec里的，同一个错再犯时没有升级路径——这就是根本区别。
4. 文档组织：领域适配 vs 框架适配 + 规范/历史分离
这个维度很有意思，它直接关系到文档结构由谁决定，以及规范与历史信息是否分离。
Trellis：框架预设固定结构，规范与历史混合
.trellis/ # Trellis规定的顶层目录
├── spec/ # 按package/layer组织的编码规范 + 学习积累
│ ├── 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）天然鼓励把历史信息写入spec。trellis-break-loop在5维度分析后也要求“update spec/guides”。Trellis没有独立的bugs/、logs/、lessons/目录——tasks/完成后归档，workspace/journal2000行轮转。学到的内容无处可去，只能沉淀到spec里。
看个实际例子。在quality-guidelines.md（982行）中，你能看到像“Case Study (2026-04-22): current_phase / next_action drift across 4 writers + type declaration”——完整的bug演化历史，包括“第一次审计漏掉了什么”、“四种漂移模式”、“最终整合结果”。还有“Cautionary tale — 0.6.0-beta.3 → 0.6.0-beta.4 emergency revert”这种版本回退事件经过，以及“Case Study (2026-04-30): issue #204 --yes + bootstrap recovery”包含commit hash、发现过程和修复过程。
同样的，workflow-state-contract.md（299行）里写道：“Two production bugs (Phase 1.3 jsonl curation skip, Phase 3.4 commit skip) hit exactly this failure mode。”
这种做法有两个面：Case Study混在规范里提供了即时的因果上下文（“为什么这条规则存在”），但代价是spec文件膨胀，AI读取时无法区分“当前规范”和“历史教训”。
AGE：按领域需要组织，规范与历史严格分离
AGE的文档组织只有两条约束：
- 渐进式披露：从最小的入口（index / start-here）逐步展开到详细内容。
- 规范与时效性历史分离：稳定文件用稳定文件名，时间敏感记录带日期。
在这两条约束内，每个项目按自己的领域需要决定文档长什么样。
nop-chaos-flux（前端低代码框架）的docs/architecture/按4层优先级组织（纲领→规范→基线→子系统），docs/components/有100个组件设计文档，docs/references/压缩最常用类型到单文件。这是前端框架的领域需要。
nop-entropy（后端全栈框架）的docs-for-ai/按编号前缀组织阅读顺序（00→04），与ai-dev/（开发过程记忆）分轨。因为使用者和开发者是完全不同的受众。
AGE Template（应用层项目）则有input/（原始PM输入）和requirements/（实现就绪需求）的分离，还有backlog/（优先级队列）。这是应用开发的领域需要。
AGE的规范/历史分离在nop-chaos-flux plan guide Rule 14里写得很明白：规范文档里允许出现的历史相关内容只有三种——选择原因（为什么选A不选B）、拒绝的替代方案及原因（否定空间）、例外记录（“有意保留的遗留行为”）。演化叙事必须留在logs/、bugs/、plans/中。
核心差异
| 维度 | Trellis | AGE |
|---|---|---|
| 文档结构决定者 | 框架（.trellis/三件套） | 领域（每个项目不同） |
| 共性约束 | 5条核心原则 + 框架结构规定 | 渐进式披露 + 规范/历史分离 |
| 规范中的历史 | 允许且鼓励（Case Study、Cautionary Tale） | 严格排除（只保留选择原因和否定空间） |
| 历史承接载体 | 无专门载体（journal轮转、tasks归档） | bugs/、logs/、plans/、lessons/ |
| spec膨胀风险 | 存在（知识只进不出） | 低（owner doc只保留当前状态） |
| 规范可读性 | 高（因果上下文就地可得） | 需跨文件引用获取上下文 |
5. Plans：闭合契约，不是任务清单
AGE的plan不是“把这件事做完”这么简单——它的设计目标是为AI全自动执行建立可验证的闭合条件。
Plan的完整生命周期
AGE的plan有三个关键门控，全部由AI独立子袋里完成：
- Draft review：独立子袋里审计scope是否诚实、closure gates是否真实、是否有隐藏依赖。
- 执行：AI围绕计划执行，每一步记录focused proof、owner doc同步、验证结果。
- Closure audit：另一个独立子袋里回到活仓库重新检查——独立验证代码、文档、测试、闭合条件是否真的满足。
nop-chaos-flux的plan guide（403行，24条最小规则）对此有明确要求：
- Rule 8：“
completed必须来自单独的closure audit。” - Rule 12：“标记
completed前，必须完成一次由独立审阅者或独立子agent执行的closure audit。” - Rule 11：“关闭计划时，必须区分'contract surface已出现'和'contract semantics已落地'。”
逐步向全自动推进
AGE的整体目标是逐步减少人类介入节点。当前实践中人仍然控制少数关键节点（定义吸引子、裁决冲突、校准方向），但plan的draft review和closure audit已经完全交给AI独立子袋里。未来的方向是：人只控制输入和最终产出，对中间过程抽样监控。
first-principles-of-agent-engineering.md对Agent的本质定义得很清楚：“Agent是一个在目标约束下，跨时间维持、验证、修正、复用可行动认知结构的系统。”Plan是验证和修正的局部载体——它定义“这轮扩张怎样才算真正完成”，然后由独立子袋里来验证。
与Trellis的对比
Trellis的计划/执行体系有两层。
第一层：PRD（设计文档 + 需求文档）。Trellis的prd.md比纯需求描述更接近设计文档——包含Goal、Assumptions、Requirements、Acceptance Criteria、Out of Scope、Decisions (ADR-lite)、Technical Notes。通过Phase 1的协作式brainstorming与用户共同创建。
第二层：通用执行流程。workflow.md定义了每个任务通用的3相位执行列表：Phase 1（1.0-1.5：创建任务→探索需求→研究→配置上下文→激活）→ Phase 2（2.1-2.3：实现→质量检查→回滚）→ Phase 3（3.1-3.5：质量验证→调试复盘→spec更新→提交→收尾）。Phase 2的实现和检查由子袋里自主完成，Phase 3.4的提交需要用户one-shot确认。
AGE的plan与Trellis的PRD+执行流程对比：
| 维度 | Trellis PRD + 3相位流程 | AGE Plan |
|---|---|---|
| 计划内容 | PRD：设计+需求+技术方案+验收标准 | Goals/Non-Goals/Closure Gates/执行项 |
| 执行列表 | 通用（workflow.md 3相位，所有任务共用） | 定制（每个plan有自己的Fix/Decision/Proof执行项） |
| Current Baseline | 无 | 强制：执行前核对活仓库 |
| Non-Goals | 有（Out of Scope段落） | 强制：防止scope drift |
| Closure Gates | 有（Acceptance Criteria，实现者自行勾选） | 强制：闭合条件，独立子袋里验证 |
| Draft review | 无 | 独立子袋里审计 |
| Closure audit | 无（实现者按Acceptance Criteria自查） | 独立子袋里回到活仓库验证 |
| 完成判定 | Phase 3.4提交前自查 | 独立closure audit证据 |
| 人的角色 | 参与PRD协作和提交确认 | 不审查中间plan，只控制输入和最终产出 |
| 自动化目标 | 人始终在环 | 逐步向全自动推进 |
Logs：自动记录的轨迹
AGE的AGENTS.md强制要求：“After completing any significant code change, you MUST update the daily dev log。”
nop-chaos-flux的docs/logs/2026/目录有72个每日日志文件，每个都记录：具体关闭了哪些plan的哪个workstream、修改了哪些代码路径（精确到文件:行号）、哪些focused proof通过了、哪些owner doc同步更新了、全仓验证状态、独立闭合审计的subagent task ID。
Trellis的等价物是workspace/journal-N.md——个人会话记忆，2000行后轮转。不记录精确的代码路径和验证基线，与plan没有关联。
6. 审计体系：共享的执行性检查 + AGE独有的方向性审计
AGE和Trellis都有代码质量门禁。区别在于AGE多了一层方向性审计。
共同基础：lint/test/typecheck作为提交门禁
Trellis的Phase 2.2（Quality check）和Phase 3.1（Quality verification）要求运行pnpm lint && pnpm typecheck && pnpm test，trellis-check skill封装了这个流程。
AGE同样有强制门禁。nop-chaos-flux的plan guide要求pnpm typecheck/build/lint/test全绿才能关闭plan；nop-entropy的AGENTS.md要求./mvnw test -pl 通过，且Rule 13明确规定“已经进入lint、静态检查脚本、或CI fail-fast的固定规则，都是不可降级的硬约束”。nop-entropy的pre-commit hook也强制代码通过格式化检查。两者在这个层面是等价的。
Trellis独有：5维度事后分析
trellis-break-loop提供结构化的bug复盘（Root Cause Category / Why Fixes Failed / Prevention / Systematic Expansion / Knowledge Capture），分析后更新spec。
AGE独有：文档+代码整体一致性审计
Deep Audit（deep-audit-prompts.md，2141行，20维度）覆盖6大类：
| 类别 | 维度 | 审计对象 |
|---|---|---|
| A. 架构与模块边界 | 01-03 | 依赖图、模块职责、API表面积 |
| B. 运行时与状态 | 04-08 | 状态所有权、响应式精度、异步安全、生命周期、验证一致性 |
| C. 渲染器与UI | 09-12 | 渲染器契约、样式合规、组件使用、字段建模 |
| D. 工程质量 | 13-15 | 类型安全、测试覆盖、安全性能 |
| E. 文档与一致性 | 16-18 | 文档-代码一致性、命名一致性、跨包模式一致性 |
| F. 运行时鲁棒性 | 19-20 | 错误传播保真度、可访问性 |
注意维度16-18——它们专门审计文档和代码之间的一致性。审计执行模型是：阶段一迭代深挖（每维度最多10轮，每轮独立子袋里），阶段二独立复核（独立子袋里回到活代码重新核对每条发现）。
Open-ended Adversarial Review（open-ended-adversarial-review-prompt.md）则完全不预设检查维度，鼓励跳跃式探索和自我否定，循环直到无新发现。
AGE多了方向性审计：owner doc是否与代码一致、命名是否与术语表一致、相同概念在不同包中是否实现一致。但deep-audit的执行成本极高（多轮独立子袋里），这是需要权衡的代价。
7. 两者的工具对比总结
| 维度 | Trellis | AGE (nop-chaos-flux / nop-entropy) |
|---|---|---|
| 工具来源 | 框架预设，安装即有 | 从历史轨迹反向提取 |
| 新项目启动成本 | trellis init即有完整工具集 | AGE Template只有通用工具，但可参考开源范例快速建立领域特定工具 |
| 工具演进机制 | trellis update (框架升级) | 晋升阶梯 (bug → lesson → prompt → script → lint) |
| 从失败中提取知识 | 有（break-loop 5维度分析 → spec prose） | 有（晋升阶梯 → 逐步自动化工具） |
| 知识产物自动化 | prose only | prose → 半自动扫描 → 全自动拦截 |
| 多平台适配 | 核心能力 (14+平台) | 不关注，依赖宿主项目的CI |
| 流程自动化 | 核心能力 (状态机、hook、子袋里) | 有限 (计划闭合检查脚本、pre-commit hook) |
| 工具维护成本 | 低（框架统一维护） | 高（每个工具需要随项目演进更新白名单和规则） |
| 规范/历史分离 | 不分离（历史沉淀到spec） | 严格分离（owner doc只含当前状态） |
| Plan系统 | PRD需求描述 | 闭合契约（draft review + closure audit） |
| 代码质量门禁 | 有（Phase 2.2/3.1: lint+typecheck+test） | 有（plan guide Rule 13: 硬门禁不可降级） |
| 事后分析 | 有（break-loop 5维度bug复盘） | 有（bug note → lesson → skill晋升） |
| 方向性审计 | 无 | 有（deep-audit 20维度含文档-代码一致性） |
8. 共同局限：Trellis和OpenSpec都是任务级工具
Trellis和OpenSpec有三个结构性的缺失。
缺失一：没有仓库整体真相
Trellis和OpenSpec的核心组织单元都是单次变更（一个task / 一个change），不是仓库整体。
- Trellis：每个task有自己的
prd.md，spec/是编码约定的堆叠。没有“系统当前整体是什么、应该收敛到哪里”的维护点。 - OpenSpec：
specs/号称source of truth，但它是需求的累加（每次archive合并delta，只增不减），不是方向定义。累加出来的specs是需求清单，不是架构吸引子。
AGE的owner doc维护的是整体方向：哪些模块必须分离、依赖只能朝哪个方向流、什么概念不允许混在一起。
AGE的first-principles-of-agent-engineering.md区分了两种事实源：四维真相（事实、因果来源、置信状态、否定空间）回答“现在是什么和曾经怎样”，吸引子回答“应该收敛到什么”。Trellis和OpenSpec都没有区分这两种事实源——它们只有“当前规范”（specs/spec），没有“方向定义”（attractor）。
缺失二：单次变更之间没有轨迹
- Trellis：task完成后归档，
journal2000行轮转。下一个task看不到上一个task做了什么、为什么这样决定、否决了什么。 - OpenSpec：change归档后保留在
archive/里，但只是历史文件夹。没有结构化的轨迹记录（代码路径、验证基线、owner doc同步状态）。下一个change不从上一个change的执行过程中学习。
AGE的logs/是强制轨迹：精确到代码路径、focused proof、owner doc同步、验证基线。bugs/记录否定空间（哪些路被排除、哪些假设被证伪）。未来的session可以从轨迹中恢复“到昨天为止发生了什么”。
这个差异来自组织单元的不同：任务级工具关心“这次变更是否正确”，仓库级方法论关心“连续多次变更之后仓库是否还在朝正确方向走”。
缺失三：没有向AI全自动演进的支撑点
- Trellis：人参与PRD协作和提交确认，3相位流程为人设计。没有独立closure audit，人最终检查。
- OpenSpec：
/opsx:propose和/opsx:verify都假设人在环。verify是可选的，没有独立验证。tasks.md是给人看的checklist。
AGE的plan有draft review和closure audit由独立AI子袋里完成，人逐步退出。plan是闭合契约，不是给人看的任务清单。吸引子定义了“收敛到哪里”，审计检查“是否在收敛”，两者都不需要人介入。
AGE的age-from-state-engineering-to-trajectory-engineering.md说得相当直接：传统软件工程的基本结构是“状态检查 + 人类隐性方向感”。AI深度参与后，人脑不再持有完整蓝图，“方向感”必须外化到仓库结构中。Trellis和OpenSpec都仍然依赖人的隐性方向感——它们让单次AI-人协作更可靠，但不替代人对方向的判断。
Trellis和OpenSpec的相对进步
两者各自比对方有进步，但都在任务级框架内打转。
Trellis相对OpenSpec的进步：
- 从失败到spec的知识回写：
trellis-break-loop（5维度bug分析）→trellis-update-spec（强制更新spec文件）。OpenSpec的/opsx:archive只合并delta specs（需求变更），不回写故障教训——学到的教训留在archive文件夹里，不回流到specs中。 - 完整的执行管线：子袋里分派（
trellis-implement/trellis-check）、jsonl上下文注入、rollback。OpenSpec只有artifact依赖图（proposal → specs → design → tasks），没有执行流程管理——/opsx:apply依赖AI自行找到并读取specs。 - 结构化的bug分析：
trellis-break-loop的5维度分析框架（Root Cause Category / Why Fixes Failed / Prevention / Systematic Expansion / Knowledge Capture）。OpenSpec没有等价物。
OpenSpec相对Trellis的进步：
- Spec强制校验：
openspec validate用Zod schema解析Markdown，强制要求Purpose段、Requirements段、每个Requirement至少一个Scenario、ADDED/MODIFIED必须含SHALL/MUST、跨section不冲突。Trellis的spec文件是完全自由的Markdown，没有结构校验。 - Delta机制：ADDED/MODIFIED/REMOVED增量描述 + archive时合并回main specs。比Trellis的“把所有知识塞进spec文件”更结构化。
- Spec/Change分离：
specs/（source of truth）和changes/（增量修改）分开。比Trellis不区分规范和提议前进了一步。
但话说回来，OpenSpec的spec格式有一个根本局限：Given/When/Then Scenario是给机器验证的格式（可自动转化为测试用例），不是给人读的方向定义。AGE的owner doc是给人读的架构方向（“模块必须分离”、“依赖只能单向流”），两者的受众完全不同。
三方对照表
| AGE维度 | AGE | OpenSpec | Trellis |
|---|---|---|---|
| 组织单元 | 仓库整体（attractor + trajectory） | 单次变更（change） | 单次变更（task） |
| 规范性质 | 方向定义（“应收敛到哪里”） | 行为描述（“当前行为”） | 编码约定（“怎么写代码”） |
| 变更之间 | 轨迹记录（logs + bugs + plans） | 归档文件夹（archive/） | 归档 + 轮转journal |
| 否定空间 | bugs/（排除的路） | 无 | 无 |
| 闭合验证 | 独立AI子袋里closure audit | 可选的/opsx:verify（自查） | Acceptance Criteria（自查） |
| AI全自动 | 概念层面支撑（plan=契约，不为人设计） | 未考虑（流程假设人在环） | 未考虑（3相位为人设计） |
| Spec校验 | 无（owner doc按领域自由组织） | 强制（Zod schema + openspec validate） | 无（自由Markdown） |
| 知识晋升 | bug → lesson → skill → script → lint | 无（archive后无递进） | 无（break-loop产出进spec即止） |
9. 理论与实践的共演
动力系统的思想（state space → attractor → trajectory → control）是AGE最早确立的概念框架。但具体如何落地——owner doc用什么结构、闭合审计怎么做、晋升阶梯怎么设计——这些都是在实践中不断调整出来的。
看看nop-chaos-flux的演化历史：
- 吸引子载体从扁平架构文档演化为4层优先级体系——在多次审计中发现优先级冲突后才固化。
- 闭合审计从人工检查演化为必须由独立子袋里验证——Plan 143的闭合假设被多次推翻后才确立。
- 晋升阶梯不是一开始设计的，而是发现“prose-only lessons无法阻止同一错误再次出现”后逐步形成的。
- open-ended adversarial review的出现是因为deep-audit的固定维度有时会错过维度之外的问题。
关键在于：具体用什么文档结构承载吸引子、用什么机制检查偏离——这些都在动力系统思想的指导下，通过实践不断校准和细化。Trellis则来自实用观察（“什么实践在AI工程中有效”），5条核心原则是经验总结。没有从理论推导实践的链路，扩展靠的是经验堆叠。
总结
核心发现就一句话：Trellis和OpenSpec都以单次变更为组织单元，AGE以仓库整体轨迹为组织单元。前者关心“这次变更是否正确”，后者关心“连续多次AI变更之后仓库是否还在朝正确方向走”。
具体来说，三者在八个维度上存在根本分歧：
- 组织单元：Trellis和OpenSpec是任务级工具（一个task / 一个change）；AGE是轨迹级方法论（仓库整体）。这是最根本的差异，以下所有分歧都由此衍生。
- 工具从哪里来：Trellis的12个skill和OpenSpec的slash commands在框架设计时预设，新项目开箱即用；AGE的工具从历史轨迹反向提取，新项目从Template通用工具起步，但可参考开源范例加速。两者面向不同的阶段需求。
- 从失败中提取知识的深度：三者都从失败中学习。Trellis的
trellis-break-loop提供5维度分析，OpenSpec有archive保留变更历史，知识沉淀为prose；AGE的晋升阶梯将同一模式逐级提升为自动化工具。区别在产物的自动化程度。 - 规范性质：OpenSpec的specs是结构化行为契约（Requirement + Scenario），比Trellis的编码约定更接近“可执行契约”。但两者都没有区分“当前行为”和“应收敛到哪里”。AGE的owner doc是方向定义，不是需求描述。
- 单次变更之间的连续性：Trellis（task归档 + journal轮转）和OpenSpec（archive文件夹）都没有结构化的轨迹记录。AGE的logs精确到代码路径和验证基线，bugs记录否定空间。
- 向AI全自动演进的支撑：Trellis和OpenSpec的流程都假设人在环。AGE的plan是闭合契约，draft review和closure audit由独立AI子袋里完成，人逐步退出。
- 审计层级：三者都有代码质量门禁。AGE多了方向性审计（deep-audit 20维度含文档-代码一致性），检查“系统是否朝正确方向收敛”，但执行成本极高。
- 理论生成 vs 经验堆叠：AGE以动力系统思想为起点，实践元素可从理论推演。Trellis和OpenSpec来自实用观察，扩展靠经验堆叠。
References
AGE方法论:
- AGE Template: github.com/entropy-clo…
~/app/attractor-guided-engineering-template/AGENTS.md— 第15条：工具晋升规则~/app/attractor-guided-engineering-template/docs/articles/attractor-before-harness-ai-large-scale-development-methodology.md— 吸引子先于线束
nop-chaos-flux (AGE实例):
- GitHub: github.com/entropy-clo…
- Gitee: gitee.com/canonical-e…
docs/skills/README.md— 22个skill/prompt索引docs/skills/deep-audit-prompts.md— 2141行，20维度深度审计框架docs/skills/open-ended-adversarial-review-prompt.md— 开放式对抗性审查docs/skills/bug-diagnosis-prompt.md— 从66+ bug中提取的诊断方法论docs/plans/00-plan-authoring-and-execution-guide.md— 403行，24条最小规则scripts/audit/— 15个文件（含11个扫描器 + 规则/共享模块）docs/bugs/— 66个bug修复历史docs/articles/first-principles-of-agent-engineering.md— 276行，Agent工程根本原则docs/articles/age-from-state-engineering-to-trajectory-engineering.md— 从状态工程到轨迹工程
nop-entropy (AGE实例):
- GitHub: github.com/entropy-clo…
- Gitee: gitee.com/canonical-e…
ai-dev/tools/rules/— 3条ast-grep Ja va lint规则docs-for-ai/INDEX.md— 规范性使用文档索引
nop-chaos-next (AGE实例):
- Gitee: gitee.com/canonical-e…
- 应用层AGE实践：
design/、input/、logs/、bugs、skills/轻量模式