# AXIOM：面向编码智能体的本地优先工作流层

> AXIOM 是一个围绕任务文件构建的确定性 CLI 工具，为编码智能体提供本地优先的工作流层，支持 git 工作树隔离、阶段产物持久化、强制验证与审查门控，以及基于 GitHub Releases 的透明发布模型。

- 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm)
- 发布时间: 2026-04-27T20:11:15.000Z
- 最近活动: 2026-04-27T20:20:11.635Z
- 热度: 161.8
- 关键词: agent, workflow, CLI, git-worktree, verification, review, local-first, deterministic, coding-agent
- 页面链接: https://www.zingnex.cn/forum/thread/axiom-1b671694
- Canonical: https://www.zingnex.cn/forum/thread/axiom-1b671694
- Markdown 来源: ingested_event

---

# AXIOM：面向编码智能体的本地优先工作流层\n\n随着 AI 编码助手和智能体（Agent）的快速发展，如何有效管理工作流、确保任务可追溯、保证输出质量成为开发团队面临的新挑战。AXIOM 项目提出了一种"本地优先"的解决方案，它不依赖持续的云端连接或特定的模型提供商，而是通过本地文件和确定性 CLI 来构建可靠的工作流层。\n\n## 核心设计理念：本地优先与确定性执行\n\nAXIOM 的核心理念是将工作流状态保存在本地文件系统中，而非聊天历史或云端服务。这种设计带来了几个显著优势：可移植性（工作可以在不同智能体主机间迁移）、可审计性（所有状态和决策都有文件记录）、以及离线可用性（不依赖网络连接即可执行）。\n\n项目明确区分了自己与传统"提示词包"或"巨型自主 IDE"的区别。AXIOM 不是预设的提示词集合，也不是试图包办一切的集成开发环境，而是一个围绕任务文件构建的确定性工作流引擎。它的职责是强制执行工作流纪律，而非替代开发者的思考。\n\n## 任务文件与生命周期管理\n\nAXIOM 为每个任务创建一个 Markdown 格式的任务文件，存储在 `.axiom/tasks/` 目录下。这些任务文件是工作的源头（source of truth），记录了任务的完整生命周期：从创建、设计、规划、执行到验证和审查。\n\n任务的生命周期通过 CLI 命令进行管理：`make` 创建任务、`run` 执行特定阶段（design/plan/execute/verify/review）、`finish` 完成任务、`list` 查看任务列表、`show` 显示任务详情、`diff` 查看变更对比。这种显式的阶段划分确保了工作按既定流程推进，每个阶段都有明确的进入和退出条件。\n\n## Git 工作树隔离与变更追踪\n\n对于支持 git 的代码仓库，AXIOM 会为每个任务自动配置独立的 git 工作树（worktree）。这种隔离机制确保不同任务之间的代码变更不会相互干扰，每个任务都在自己的独立环境中执行。\n\n任务创建时会记录不可变的 base_commit，后续的所有变更都相对于这个基准点进行追踪。任务范围的差异对比（task-scoped diff）和变更文件追踪帮助审查者了解实际修改了哪些文件，确保变更在计划范围内。即使是未跟踪的新文件，其内容也会被纳入差异证据中。\n\n## 强制验证与审查门控\n\nAXIOM 在任务完成前设置了强制性的验证（verify）和审查（review）门控。验证阶段支持运行自动化测试命令，并通过工具代理（tool broker）执行，具备策略检查、超时控制、输出捕获限制等功能。审查阶段则对比计划写入范围与实际变更范围，记录范围匹配情况。\n\n这些门控不是形式化的流程步骤，而是真正的阻塞点。如果验证失败、文档未解决、没有任务差异，或者变更文件超出了计划的写入范围，AXIOM 会在任何语义审查之前返回 "changes_requested" 或 "blocked" 状态。这种设计确保了工作质量，防止未经充分验证的代码进入完成状态。\n\n## 命令适配器协议与扩展性\n\nAXIOM 提供了一个命令适配器协议，允许集成本地模型包装器或主机智能体。适配器通过标准输入接收结构化的 JSON 请求，通过标准输出返回 JSON 响应。当前支持在 `run plan`、`run execute` 和可选的 `run review` 阶段调用适配器。\n\n项目提供了多个参考适配器实现：静态计划适配器、文件写入执行适配器、OpenAI 兼容的计划/审查包装器等。这种设计使得 AXIOM 可以与各种本地模型或智能体框架集成，而不绑定到特定的提供商。\n\n值得注意的是，命令适配器被视为受信任的本地命令，而非沙箱环境。在锁定环境中，建议使用适配器白名单或哈希锁定来确保安全。\n\n## 发布透明度与供应链安全\n\nAXIOM 采用"源头优先"的发布透明度模型，基于 GitHub Releases 和 GitHub Actions 构建。每个标记的发布版本预期会发布 wheel、源代码分发包、SHA256SUMS、SBOM.spdx.json 以及 GitHub 工件证明（artifact attestations）。\n\n这种发布模式让用户能够验证所安装的二进制文件确实来自声明的源代码，并审查其依赖关系。在当前软件供应链安全日益受到关注的背景下，这种透明度和可审计性是一个重要特性。\n\n## 适用场景与部署模式\n\nAXIOM 适用于需要结构化工作流管理的编码项目，特别是涉及多个并行任务、需要严格变更审查、或者团队希望建立一致工作规范的场景。它支持多种部署模式：作为 PATH 中的中央安装、内部镜像或伴生仓库、或者作为项目本地工具进行 vendoring。\n\n对于希望引入 AI 辅助编码但又担心失去控制的企业团队，AXIOM 提供了一个平衡的方案：既允许利用智能体的能力，又通过严格的门控和审计机制保持人工监督。\n\n## 当前状态与未来方向\n\n目前 AXIOM 已经实现了核心的本地工作流和发布透明度功能，包括任务文件生命周期、git 工作树配置、阶段产物持久化、命令适配器协议、验证和审查门控等。项目仍在积极开发中，计划中的功能包括更完善的本地模型服务器集成、可重现构建、以及原生 macOS 签名支持。\n\nAXIOM 代表了一种对 AI 辅助开发工具的审慎态度：技术应该增强人类开发者的能力，而非取代人类的判断和责任。通过将工作流状态保存在本地、强制执行验证门控、保持发布透明度，AXIOM 为这种协作模式提供了一个坚实的基础。