AXI 中文教程：先改一个只读命令
AXI 的全名是 Agent eXperience Interface。它不是新的代理运行时，而是一套让命令行更适合代理调用的设计原则：减少默认字段，提供可恢复的截断，明确空结果，用退出码和结构化错误帮助模型修正下一步。
1. 记录改造前的基线
选择一个只有读取权限、结果容易判断的任务，例如列出三个开放 issue。固定模型、提示和账号，记录成功率、输入输出 token、工具回合数、耗时和错误类型。没有基线，就无法判断压缩输出是否真的帮助了代理。
2. 逐条应用十条原则
先处理最容易验证的四项：默认只返回决策所需字段；空结果明确写出空状态；错误包含稳定代码和下一步；过长内容截断时报告原始大小，并提供 --full 逃生口。之后再评估预计算汇总、环境上下文和结果后的下一步提示。
# 示例接口形状，不是 AXI 仓库中的固定命令 issues list --limit 3 issues list --limit 3 --full
3. 评估参考实现时单独看权限
官方目录列出 gh-axi、chrome-devtools-axi、lavish-axi 和 quota-axi 等实现。它们属于不同仓库，安装前要分别核对包名、维护者和权限。GitHub 测试使用只读 token，浏览器测试使用没有个人登录状态的独立配置。
若使用 JavaScript SDK，要求 Node.js 20 以上；仓库开发配置使用 pnpm 11.1.1，并依赖 TOON 格式包。SDK 能帮助组织输出，但不会替具体工具处理认证和业务权限。
4. 用自己的任务重复测试
AXI README 报告了 490 次浏览器运行和 425 次 GitHub 运行，使用 Claude Sonnet 4.6 比较多个条件。这些是项目方维护的结果，任务选择、提示、模型和版本都影响结论。采用前至少重复多个回合，并把失败恢复和权限事故一起计入。
与 MCP 对比
MCP 官方架构由 host、client 和 server 组成，处理能力协商、服务发现以及上下文和工具的标准连接。AXI 关注 shell 命令的输出和错误是否适合代理。需要统一连接与跨工具生态时评估 MCP；已有 CLI 但输出冗长、恢复困难时借鉴 AXI。一个 MCP server 背后也可以调用遵循 AXI 原则的 CLI。
这里仅补原教程没有展开的事实和边界。安装命令与操作步骤仍以前文为准。
先判断这个项目是否适合你
适合谁用
适合为代理设计或改造 CLI、评估输出压缩与错误恢复，以及建立接口对照实验。不适合仅凭官方基准就替换现有 MCP 集成；身份、连接生命周期、跨语言 SDK 或集中发现等需求应单独评估。
原教程未展开的系统信息
核心功能
十条 CLI 原则
覆盖紧凑输出、最小默认 schema、可恢复截断、预计算汇总、明确空状态、结构化错误、环境上下文、内容优先、下一步提示和一致帮助。
JavaScript SDK 与 skill
仓库提供用于构建 AXI 输出的 JavaScript SDK，也提供代理技能文件解释原则和示例。
核验与使用边界
优势与限制
优势
- 把 token 和回合数转成具体 CLI 设计规则
- 公开任务矩阵和基准工具
- 原则可逐条应用到已有命令行
限制
- 基准由项目方设计和执行，并非独立评测
- 结果绑定任务集、模型和当时版本，不能外推到所有代理
- AXI 不提供 MCP 的统一 host、client、server 架构
排错时先核对版本、运行环境和未覆盖范围。这里没有执行过的步骤不会写成实测结论。
常见问题
AXI 是一个可以直接运行的代理框架吗？
不是。AXI 主体是十条 CLI 设计原则、基准、skill、SDK 和实现目录；具体操作 GitHub 或浏览器要使用对应的独立 CLI。
axi-sdk-js v0.1.12 是整个 AXI 项目的版本吗？
不是。v0.1.12 是 JavaScript SDK 子包的正式版本。原则文档、基准和各参考实现有各自的维护节奏。
AXI 官方基准能证明它普遍优于 MCP 吗？
不能。数据来自项目方在指定任务和 Claude Sonnet 4.6 上的自建测试，适合提出假设，采用前仍需用自己的任务、模型和权限环境复测。
AXI 和 MCP 能一起使用吗？
可以。MCP 负责标准化 host、client 与 server 的连接；AXI 原则可用于优化某个 CLI 或 MCP server 背后的命令输出，两者解决的层级不同。