Flow-Next — repo-native agentic engineering workflow
Flow-Next — repo-native agentic engineering workflow
为什么重要
Flow-Next 值得进入 wiki，不是因为它又是一个 Claude Code 插件，而是因为它把最近几周反复出现的 Harness-Engineering 主线落成了一个 repo-native artifact chain：从 rough intent 到 durable spec、task graph、fresh-context worker、cross-model review、implementation receipt。它的核心判断是：当 agentic coding 把实现压缩到一次长 run 时，传统敏捷里靠站会、走廊沟通、人工中途纠偏补上的信息会消失，spec 和 review gate 必须承载这部分缺失对话。
这对用户的 Hermes / llm-wiki 实践很直接：无人 cron、wiki ingest、代码修改和自动发布都不应只留下“我完成了”的自然语言，而要留下可审查的中间对象：意图、任务切片、验证、review verdict、receipt。Flow-Next 是这一思路在 coding-agent workflow 层的高信号实现。
机制 / 一阶原理
Flow-Next 的机制可以概括为：把长程 agentic coding 拆成可冻结、可复查、可交接的 artifact pipeline。
- Spec-driven：工作单元不是聊天记录或 PR 标题，而是
.flow/specs/<id>.md这类 durable spec。 - Context-fit planning：spec 被拆成 dependency-ordered tasks，每个 task 适配一个 fresh context worker，而不是让一个 agent 在巨长上下文里一路漂移。
- Re-anchored workers：worker 在每个任务开始前重新读取 spec、task 和 git state，降低 token bleed、旧假设和上下文污染。
- Adversarial gates：计划和实现都由不同模型/工具面做 review；不同模型错误分布不同，分歧本身是发现缺口的信号。
- Receipts：完成不是叙述，而是 commit、测试、review verdict、证据的组合。
- Repo ownership：所有 spec、task、memory、receipt 都在 repo 内，可版本化、可 code review、可删除。
一阶原理是：agent 的生成能力越强，越需要把“隐性协调成本”外化为稳定对象。否则，速度提升会把瓶颈推向需求模糊、review 失焦和验证自证。
与既有 wiki 概念的关系
- 对 Spec-driven-development：Flow-Next 是 spec-driven 在多 agent / 多模型 review / receipt 层的 workflow 化实现。
- 对 Harness-Engineering：它把 harness 从 prompt/rules 扩展到 lifecycle objects 与 adversarial gates。
- 对 Context-Engineering：fresh-context worker 和 task-sized slicing 说明上下文不是越多越好，而要按任务边界重锚定。
- 对 Agentic-Coding：它把“agent 会写代码”推进到“agent 在可审计流程里交付可验证工程变更”。
- 对 Loop-Engineering：Flow-Next 的 memory、glossary、decision records 和 receipts 是未来长期 loop 的状态材料。
对 Hermes / llm-wiki 的可执行启发
- 把每日 radar 的输出也做成 artifact chain：candidate digest、raw archive、source page、concept update、index/log、reindex、最终报告分别承担不同验证职责。
- 复杂代码任务默认 fresh-context slicing：先将目标拆为独立 task，并让每个 worker 重新读取必要 spec/文件，而不是把全部历史塞给一个 agent。
- 报告必须 receipt-first：最终回复应列出实际创建/更新文件、执行命令、验证输出和未验证事项，避免用叙述替代证据。
- review 可以跨模型/跨工具面：重要 patch 或 wiki 重构可引入独立 review worker，专门找遗漏、重复页、断链和未证实 claim。
- repo-native 优先：知识库、skills、cron prompt、评测规则都应尽量以 markdown / TOML / JSON 等文件存在，便于版本化和 diff。
失败模式 / 边界条件
- 流程过重：小修小补如果强制走完整 pipeline，成本可能超过收益；需要按风险和范围分级。
- review 自证：如果 adversarial gate 只是同一模型、同一上下文的重复总结，分歧价值会很低。
- receipt 膨胀：大量 receipts 若缺少索引和摘要，会变成新的上下文噪音。
- spec 冻结过早：需求仍高度不确定时，过早冻结 spec 可能把错误假设制度化。
- 插件生态锁定：README 显示 Flow-Next 支持多 harness，但当前证据主要来自项目 README；真实跨工具稳定性仍需后续验证。
深度判断
本条 deep ingest 的理由是：Flow-Next 与既有 Harness-Engineering、Context-Engineering、Agentic-Coding 多条主线高度交叉，并提供了可复用的 workflow object vocabulary（spec、task、fresh worker、adversarial review、receipt）。它不是薄工具清单，而是能直接改进 Hermes 任务完成定义和 llm-wiki ingest 证据链的结构性材料。置信度标为 medium，因为当前主要依据 README，尚未实测其插件与 CLI。
写入记录
- 2026-07-21 09:01 CST：新增 Flow-Next source 页，提炼 repo-native artifact chain、fresh-context workers、adversarial gates 与 receipts 对 Hermes/llm-wiki 的启发。