简介Trellis 是一个第三方开源模板 (mindfoldhq/trellis)目标是让 AI 编码代理在 14 平台上有一致的工程流程。OpenSpec 是一个类似的第三方开源框架 (fission-ai/openspec)目标是spec-driven development通过 delta specs 管理变更AGE (Attractor-Guided Engineering)是从 nop-chaos-flux 的实践中长出来的方法论核心思想是状态空间 - 吸引子 - 轨迹 - 控制微信公众号系列文章《Attractor Before Harness: AI 大规模开发的方法论》《从 Spec-Driven Development 到 Attractor-Guided Engineering》《为什么 Attractor Guided Engineering 不能被降级为 AI Agent Skill》《控制层和方向层的分野OpenProse、NLAHs 与 AGE》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 个 skill5 条核心原则Plan before code、Specs injected not remembered、Persist everything、Incremental development、Capture learningsOpenSpec一个产品化的 spec-driven 框架通过npm install -g fission-ai/openspec openspec init安装核心模型是 spec delta archive 循环specs/source of truth← merge ←changes/delta specs每个 change 包含 proposal → specs → design → tasks 四种 artifact按 schema 依赖图生成Delta specs 用 ADDED/MODIFIED/REMOVED 描述增量修改archive 时合并回 main specs4 条哲学fluid not rigid、iterative not waterfall、easy not complex、brownfield-first支持 25 AI 工具的 slash command 集成AGE一个方法论不是产品。没有 npm 包没有安装命令AGE Template 是一个复制即用的文档骨架https://github.com/entropy-cloud/attractor-guided-engineering-template 定义文档职责和流程附带通用工具check-doc-links、check-oversized-files等。领域特定工具需要从实践中提取AGE 作者开源了多个大型范例项目展示 AGE 在不同领域的完整实践nop-chaos-fluxhttps://github.com/entropy-cloud/nop-chaos-flux 前端低代码框架15 个审计文件含 11 个扫描器、22 个 prompt、66 个 bug note、72 个日志nop-entropyhttps://github.com/entropy-cloud/nop-entropy 后端全栈框架docs-for-ai/规范文档 ai-dev/开发记忆分轨nop-chaos-nexthttps://gitee.com/canonical-entropy/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构成了一套从失败中提取知识的机制详见第 3 节。AGE工具从实践中逐步提炼nop-chaos-flux 的工具生长链路清晰可见链路 1硬编码类型分发 → audit scriptBug 发现渲染器中存在硬编码的 type switch → 审计发现违反渲染器应通过注册表分发的架构契约 → Plan 430: eliminate-hardcoded-type-dispatch-plan → 提取为脚本: scripts/audit/find-hardcoded-type-dispatch.mjs → 规则编码在: scripts/audit/rules.mjs链路 2渲染器 marker 缺失 → audit scriptBug 发现渲染器未按契约输出 marker class → 多次出现在 deep audit 维度 09 → 提取为脚本: scripts/audit/find-missing-renderer-markers.mjs链路 3-5响应式订阅不精确、async 无失败路径、React 19 遗留 API → 各自对应的 audit scriptnop-entropy 同样遵循这个模式Bug 发现Java 代码中使用裸 RuntimeException → 约定应使用 NopException 子类 → 提取为 ast-grep 规则: ai-dev/tools/rules/java-lint-bare-runtimeexception.yml开箱即用 vs 逐步积累Trellis 新项目立即拥有完整的 12 个 skill 工作流状态机 跨平台 hook。AGE 新项目从 Template 起步只有通用工具但可以参考 nop-chaos-flux、nop-entropy、nop-chaos-next 等开源范例来快速建立领域特定工具。Trellis 适合今天就开始AGE 适合长期演化。3. 从失败中提取知识两种不同深度的机制Trellis 和 AGE 都从失败中提取知识但产物形式和自动化程度不同。Trellis提取到 prose spectrellis-break-loop提供了结构化的 5 维度 bug 分析框架Root Cause Category5 类Missing Spec / Cross-Layer Contract / Change Propagation Failure / Test Coverage Gap / Implicit AssumptionWhy Fixes Failed4 种失败模式Surface Fix / Incomplete Scope / Tool Limitation / Mental ModelPrevention Mechanisms6 种预防机制Documentation / Architecture / Compile-time / Runtime / Test Coverage / Code ReviewSystematic 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 等形式沉淀为 prose。AGE提取到逐步自动化的工具AGE 的晋升阶梯AGE Template AGENTS.md Rule 15Level 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 闭合审计中提取的契约审查方法核心差异两者都从失败中提取知识但产物的形式和自动化程度不同维度TrellisAGE分析框架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 条核心原则Plan before code、Persist everything 等是跨项目的共性约束。规范与历史没有分离。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.md982 行中的历史性内容“Case Study (2026-04-22):current_phase/next_actiondrift 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.md299 行中“Two production bugs (Phase 1.3 jsonl curation skip, Phase 3.4 commit skip) hit exactly this failure mode.”Case Study 混在规范中提供了即时的因果上下文“为什么这条规则存在”AGE 则需要跨文件引用才能获得同样的上下文。代价是 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 明确规定docs/architecture/下的文档只描述当前最新设计状态。不写历史变迁、不写Proposed vs Current对比、不写演进叙事。规范文档里允许出现的历史相关内容只有三种选择原因为什么选 A 不选 B、拒绝的替代方案及原因否定空间、例外记录“有意保留的遗留行为”。演化叙事必须留在logs/、bugs/、plans/中。核心差异维度TrellisAGE文档结构决定者框架.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 guide403 行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 11.0-1.5创建任务→探索需求→研究→配置上下文→激活→ Phase 22.1-2.3实现→质量检查→回滚→ Phase 33.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 driftClosure 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.2Quality check和 Phase 3.1Quality verification要求运行pnpm lint pnpm typecheck pnpm testtrellis-checkskill 封装了这个流程。AGE 同样有强制门禁。nop-chaos-flux 的 plan guide 要求pnpm typecheck/build/lint/test全绿才能关闭 plannop-entropy 的 AGENTS.md 要求./mvnw test -pl affected-module -ampasses且 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 Auditdeep-audit-prompts.md2141 行20 维度覆盖 6 大类类别维度审计对象A. 架构与模块边界01-03依赖图、模块职责、API 表面积B. 运行时与状态04-08状态所有权、响应式精度、异步安全、生命周期、验证一致性C. 渲染器与 UI09-12渲染器契约、样式合规、组件使用、字段建模D. 工程质量13-15类型安全、测试覆盖、安全性能E. 文档与一致性16-18文档-代码一致性、命名一致性、跨包模式一致性F. 运行时鲁棒性19-20错误传播保真度、可访问性维度 16-18专门审计文档和代码之间的一致性。审计执行模型阶段一迭代深挖每维度最多 10 轮每轮独立子代理阶段二独立复核独立子代理回到活代码重新核对每条发现。Open-ended Adversarial Reviewopen-ended-adversarial-review-prompt.md不预设检查维度鼓励跳跃式探索和自我否定循环直到无新发现。AGE 多了方向性审计owner doc 是否与代码一致、命名是否与术语表一致、相同概念在不同包中是否实现一致。deep-audit 执行成本极高多轮独立子代理这是需要权衡的代价。7. 两者的工具对比总结维度TrellisAGE (nop-chaos-flux / nop-entropy)工具来源框架预设安装即有从历史轨迹反向提取新项目启动成本trellis init即有完整工具集AGE Template 只有通用工具但可参考开源范例nop-chaos-flux、nop-entropy快速建立领域特定工具工具演进机制trellis update(框架升级)晋升阶梯 (bug → lesson → prompt → script → lint)从失败中提取知识有break-loop 5 维度分析 → spec prose有晋升阶梯 → 逐步自动化工具知识产物自动化prose onlyprose → 半自动扫描 → 全自动拦截多平台适配核心能力 (14 平台)不关注依赖宿主项目的 CI流程自动化核心能力 (状态机、hook、子代理)有限 (计划闭合检查脚本、pre-commit hook)工具维护成本低框架统一维护高每个工具需要随项目演进更新白名单和规则规范/历史分离不分离历史沉淀到 spec严格分离owner doc 只含当前状态Plan 系统PRD 需求描述闭合契约draft review closure audit代码质量门禁有Phase 2.2/3.1: linttypechecktest有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.mdspec/是编码约定的堆叠。没有系统当前整体是什么、应该收敛到哪里的维护点OpenSpecspecs/号称 source of truth但它是需求的累加每次 archive 合并 delta只增不减不是方向定义。累加出来的 specs 是需求清单不是架构吸引子AGE 的 owner doc 维护的是整体方向哪些模块必须分离、依赖只能朝哪个方向流、什么概念不允许混在一起。AGE 的first-principles-of-agent-engineering.md区分了两种事实源四维真相事实、因果来源、置信状态、否定空间回答现在是什么和曾经怎样吸引子回答应该收敛到什么。Trellis 和 OpenSpec 都没有区分这两种事实源——它们只有当前规范specs/spec没有方向定义attractor。缺失二单次变更之间没有轨迹Trellistask 完成后归档journal2000 行轮转。下一个 task 看不到上一个 task 做了什么、为什么这样决定、否决了什么OpenSpecchange 归档后保留在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 是给人看的 checklistAGE 的 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-loop5 维度 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 维度AGEOpenSpecTrellis组织单元仓库整体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 / 一个 changeAGE 是轨迹级方法论仓库整体。这是最根本的差异以下所有分歧都由此衍生。工具从哪里来Trellis 的 12 个 skill 和 OpenSpec 的 slash commands 在框架设计时预设新项目开箱即用AGE 的工具从历史轨迹反向提取新项目从 Template 通用工具起步但可参考 nop-chaos-flux、nop-entropy、nop-chaos-next 等开源范例加速。两者面向不同的阶段需求。从失败中提取知识的深度三者都从失败中学习。Trellis 的trellis-break-loop提供 5 维度分析OpenSpec 有 archive 保留变更历史知识沉淀为 proseAGE 的晋升阶梯将同一模式逐级提升为自动化工具。区别在产物的自动化程度。规范性质OpenSpec 的 specs 是结构化行为契约Requirement Scenario比 Trellis 的编码约定更接近可执行契约。但两者都没有区分当前行为和应收敛到哪里。AGE 的 owner doc 是方向定义不是需求描述。单次变更之间的连续性Trellistask 归档 journal 轮转和 OpenSpecarchive 文件夹都没有结构化的轨迹记录。AGE 的 logs 精确到代码路径和验证基线bugs 记录否定空间。向 AI 全自动演进的支撑Trellis 和 OpenSpec 的流程都假设人在环。AGE 的 plan 是闭合契约draft review 和 closure audit 由独立 AI 子代理完成人逐步退出。审计层级三者都有代码质量门禁。AGE 多了方向性审计deep-audit 20 维度含文档-代码一致性检查系统是否朝正确方向收敛但执行成本极高。理论生成 vs 经验堆叠AGE 以动力系统思想为起点实践元素可从理论推演。Trellis 和 OpenSpec 来自实用观察扩展靠经验堆叠。ReferencesAGE 方法论:AGE Template: https://github.com/entropy-cloud/attractor-guided-engineering-template~/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: https://github.com/entropy-cloud/nop-chaos-fluxGitee: https://gitee.com/canonical-entropy/nop-chaos-fluxdocs/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: https://github.com/entropy-cloud/nop-entropyGitee: https://gitee.com/canonical-entropy/nop-entropyai-dev/tools/rules/— 3 条 ast-grep Java lint 规则docs-for-ai/INDEX.md— 规范性使用文档索引nop-chaos-next (AGE 实例):Gitee: https://gitee.com/canonical-entropy/nop-chaos-next应用层 AGE 实践design/、input/、logs/、bugs、skills/轻量模式
任务级工具 vs 轨迹级方法论：Trellis、OpenSpec 与 AGE 的根本分歧
简介Trellis 是一个第三方开源模板 (mindfoldhq/trellis)目标是让 AI 编码代理在 14 平台上有一致的工程流程。OpenSpec 是一个类似的第三方开源框架 (fission-ai/openspec)目标是spec-driven development通过 delta specs 管理变更AGE (Attractor-Guided Engineering)是从 nop-chaos-flux 的实践中长出来的方法论核心思想是状态空间 - 吸引子 - 轨迹 - 控制微信公众号系列文章《Attractor Before Harness: AI 大规模开发的方法论》《从 Spec-Driven Development 到 Attractor-Guided Engineering》《为什么 Attractor Guided Engineering 不能被降级为 AI Agent Skill》《控制层和方向层的分野OpenProse、NLAHs 与 AGE》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 个 skill5 条核心原则Plan before code、Specs injected not remembered、Persist everything、Incremental development、Capture learningsOpenSpec一个产品化的 spec-driven 框架通过npm install -g fission-ai/openspec openspec init安装核心模型是 spec delta archive 循环specs/source of truth← merge ←changes/delta specs每个 change 包含 proposal → specs → design → tasks 四种 artifact按 schema 依赖图生成Delta specs 用 ADDED/MODIFIED/REMOVED 描述增量修改archive 时合并回 main specs4 条哲学fluid not rigid、iterative not waterfall、easy not complex、brownfield-first支持 25 AI 工具的 slash command 集成AGE一个方法论不是产品。没有 npm 包没有安装命令AGE Template 是一个复制即用的文档骨架https://github.com/entropy-cloud/attractor-guided-engineering-template 定义文档职责和流程附带通用工具check-doc-links、check-oversized-files等。领域特定工具需要从实践中提取AGE 作者开源了多个大型范例项目展示 AGE 在不同领域的完整实践nop-chaos-fluxhttps://github.com/entropy-cloud/nop-chaos-flux 前端低代码框架15 个审计文件含 11 个扫描器、22 个 prompt、66 个 bug note、72 个日志nop-entropyhttps://github.com/entropy-cloud/nop-entropy 后端全栈框架docs-for-ai/规范文档 ai-dev/开发记忆分轨nop-chaos-nexthttps://gitee.com/canonical-entropy/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构成了一套从失败中提取知识的机制详见第 3 节。AGE工具从实践中逐步提炼nop-chaos-flux 的工具生长链路清晰可见链路 1硬编码类型分发 → audit scriptBug 发现渲染器中存在硬编码的 type switch → 审计发现违反渲染器应通过注册表分发的架构契约 → Plan 430: eliminate-hardcoded-type-dispatch-plan → 提取为脚本: scripts/audit/find-hardcoded-type-dispatch.mjs → 规则编码在: scripts/audit/rules.mjs链路 2渲染器 marker 缺失 → audit scriptBug 发现渲染器未按契约输出 marker class → 多次出现在 deep audit 维度 09 → 提取为脚本: scripts/audit/find-missing-renderer-markers.mjs链路 3-5响应式订阅不精确、async 无失败路径、React 19 遗留 API → 各自对应的 audit scriptnop-entropy 同样遵循这个模式Bug 发现Java 代码中使用裸 RuntimeException → 约定应使用 NopException 子类 → 提取为 ast-grep 规则: ai-dev/tools/rules/java-lint-bare-runtimeexception.yml开箱即用 vs 逐步积累Trellis 新项目立即拥有完整的 12 个 skill 工作流状态机 跨平台 hook。AGE 新项目从 Template 起步只有通用工具但可以参考 nop-chaos-flux、nop-entropy、nop-chaos-next 等开源范例来快速建立领域特定工具。Trellis 适合今天就开始AGE 适合长期演化。3. 从失败中提取知识两种不同深度的机制Trellis 和 AGE 都从失败中提取知识但产物形式和自动化程度不同。Trellis提取到 prose spectrellis-break-loop提供了结构化的 5 维度 bug 分析框架Root Cause Category5 类Missing Spec / Cross-Layer Contract / Change Propagation Failure / Test Coverage Gap / Implicit AssumptionWhy Fixes Failed4 种失败模式Surface Fix / Incomplete Scope / Tool Limitation / Mental ModelPrevention Mechanisms6 种预防机制Documentation / Architecture / Compile-time / Runtime / Test Coverage / Code ReviewSystematic 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 等形式沉淀为 prose。AGE提取到逐步自动化的工具AGE 的晋升阶梯AGE Template AGENTS.md Rule 15Level 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 闭合审计中提取的契约审查方法核心差异两者都从失败中提取知识但产物的形式和自动化程度不同维度TrellisAGE分析框架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 条核心原则Plan before code、Persist everything 等是跨项目的共性约束。规范与历史没有分离。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.md982 行中的历史性内容“Case Study (2026-04-22):current_phase/next_actiondrift 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.md299 行中“Two production bugs (Phase 1.3 jsonl curation skip, Phase 3.4 commit skip) hit exactly this failure mode.”Case Study 混在规范中提供了即时的因果上下文“为什么这条规则存在”AGE 则需要跨文件引用才能获得同样的上下文。代价是 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 明确规定docs/architecture/下的文档只描述当前最新设计状态。不写历史变迁、不写Proposed vs Current对比、不写演进叙事。规范文档里允许出现的历史相关内容只有三种选择原因为什么选 A 不选 B、拒绝的替代方案及原因否定空间、例外记录“有意保留的遗留行为”。演化叙事必须留在logs/、bugs/、plans/中。核心差异维度TrellisAGE文档结构决定者框架.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 guide403 行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 11.0-1.5创建任务→探索需求→研究→配置上下文→激活→ Phase 22.1-2.3实现→质量检查→回滚→ Phase 33.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 driftClosure 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.2Quality check和 Phase 3.1Quality verification要求运行pnpm lint pnpm typecheck pnpm testtrellis-checkskill 封装了这个流程。AGE 同样有强制门禁。nop-chaos-flux 的 plan guide 要求pnpm typecheck/build/lint/test全绿才能关闭 plannop-entropy 的 AGENTS.md 要求./mvnw test -pl affected-module -ampasses且 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 Auditdeep-audit-prompts.md2141 行20 维度覆盖 6 大类类别维度审计对象A. 架构与模块边界01-03依赖图、模块职责、API 表面积B. 运行时与状态04-08状态所有权、响应式精度、异步安全、生命周期、验证一致性C. 渲染器与 UI09-12渲染器契约、样式合规、组件使用、字段建模D. 工程质量13-15类型安全、测试覆盖、安全性能E. 文档与一致性16-18文档-代码一致性、命名一致性、跨包模式一致性F. 运行时鲁棒性19-20错误传播保真度、可访问性维度 16-18专门审计文档和代码之间的一致性。审计执行模型阶段一迭代深挖每维度最多 10 轮每轮独立子代理阶段二独立复核独立子代理回到活代码重新核对每条发现。Open-ended Adversarial Reviewopen-ended-adversarial-review-prompt.md不预设检查维度鼓励跳跃式探索和自我否定循环直到无新发现。AGE 多了方向性审计owner doc 是否与代码一致、命名是否与术语表一致、相同概念在不同包中是否实现一致。deep-audit 执行成本极高多轮独立子代理这是需要权衡的代价。7. 两者的工具对比总结维度TrellisAGE (nop-chaos-flux / nop-entropy)工具来源框架预设安装即有从历史轨迹反向提取新项目启动成本trellis init即有完整工具集AGE Template 只有通用工具但可参考开源范例nop-chaos-flux、nop-entropy快速建立领域特定工具工具演进机制trellis update(框架升级)晋升阶梯 (bug → lesson → prompt → script → lint)从失败中提取知识有break-loop 5 维度分析 → spec prose有晋升阶梯 → 逐步自动化工具知识产物自动化prose onlyprose → 半自动扫描 → 全自动拦截多平台适配核心能力 (14 平台)不关注依赖宿主项目的 CI流程自动化核心能力 (状态机、hook、子代理)有限 (计划闭合检查脚本、pre-commit hook)工具维护成本低框架统一维护高每个工具需要随项目演进更新白名单和规则规范/历史分离不分离历史沉淀到 spec严格分离owner doc 只含当前状态Plan 系统PRD 需求描述闭合契约draft review closure audit代码质量门禁有Phase 2.2/3.1: linttypechecktest有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.mdspec/是编码约定的堆叠。没有系统当前整体是什么、应该收敛到哪里的维护点OpenSpecspecs/号称 source of truth但它是需求的累加每次 archive 合并 delta只增不减不是方向定义。累加出来的 specs 是需求清单不是架构吸引子AGE 的 owner doc 维护的是整体方向哪些模块必须分离、依赖只能朝哪个方向流、什么概念不允许混在一起。AGE 的first-principles-of-agent-engineering.md区分了两种事实源四维真相事实、因果来源、置信状态、否定空间回答现在是什么和曾经怎样吸引子回答应该收敛到什么。Trellis 和 OpenSpec 都没有区分这两种事实源——它们只有当前规范specs/spec没有方向定义attractor。缺失二单次变更之间没有轨迹Trellistask 完成后归档journal2000 行轮转。下一个 task 看不到上一个 task 做了什么、为什么这样决定、否决了什么OpenSpecchange 归档后保留在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 是给人看的 checklistAGE 的 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-loop5 维度 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 维度AGEOpenSpecTrellis组织单元仓库整体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 / 一个 changeAGE 是轨迹级方法论仓库整体。这是最根本的差异以下所有分歧都由此衍生。工具从哪里来Trellis 的 12 个 skill 和 OpenSpec 的 slash commands 在框架设计时预设新项目开箱即用AGE 的工具从历史轨迹反向提取新项目从 Template 通用工具起步但可参考 nop-chaos-flux、nop-entropy、nop-chaos-next 等开源范例加速。两者面向不同的阶段需求。从失败中提取知识的深度三者都从失败中学习。Trellis 的trellis-break-loop提供 5 维度分析OpenSpec 有 archive 保留变更历史知识沉淀为 proseAGE 的晋升阶梯将同一模式逐级提升为自动化工具。区别在产物的自动化程度。规范性质OpenSpec 的 specs 是结构化行为契约Requirement Scenario比 Trellis 的编码约定更接近可执行契约。但两者都没有区分当前行为和应收敛到哪里。AGE 的 owner doc 是方向定义不是需求描述。单次变更之间的连续性Trellistask 归档 journal 轮转和 OpenSpecarchive 文件夹都没有结构化的轨迹记录。AGE 的 logs 精确到代码路径和验证基线bugs 记录否定空间。向 AI 全自动演进的支撑Trellis 和 OpenSpec 的流程都假设人在环。AGE 的 plan 是闭合契约draft review 和 closure audit 由独立 AI 子代理完成人逐步退出。审计层级三者都有代码质量门禁。AGE 多了方向性审计deep-audit 20 维度含文档-代码一致性检查系统是否朝正确方向收敛但执行成本极高。理论生成 vs 经验堆叠AGE 以动力系统思想为起点实践元素可从理论推演。Trellis 和 OpenSpec 来自实用观察扩展靠经验堆叠。ReferencesAGE 方法论:AGE Template: https://github.com/entropy-cloud/attractor-guided-engineering-template~/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: https://github.com/entropy-cloud/nop-chaos-fluxGitee: https://gitee.com/canonical-entropy/nop-chaos-fluxdocs/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: https://github.com/entropy-cloud/nop-entropyGitee: https://gitee.com/canonical-entropy/nop-entropyai-dev/tools/rules/— 3 条 ast-grep Java lint 规则docs-for-ai/INDEX.md— 规范性使用文档索引nop-chaos-next (AGE 实例):Gitee: https://gitee.com/canonical-entropy/nop-chaos-next应用层 AGE 实践design/、input/、logs/、bugs、skills/轻量模式
