代理友好 ≠ 代理原生：我们的CLI有67个命令，但代理仍无法运行一个任务

我一直在重新设计我负责的一个批量执行编译器的CLI。它已经发展到67个叶子命令，并且在技术上是‘代理友好型’的——结构化输出、稳定的退出代码、非交互式、机器可读的帮助。所有条件都满足了。代理在最简单的任务上仍然失败了：‘运行这个工作并给我结果。’以下是原因。运行一个工作根据输入的不同而看起来不同：template submit-file run execute template-spec submit-workbook template-spec run market run market workbook run 每条路径都重命名了验证步骤——validate-file vs validate vs validate-workbook。因此，在代理能够根据其意图行动之前，它必须重建我们的整个资源模型：这是一个模板吗？一个私有规格吗？一个市场项目吗？每一个都是可能出错并消耗一批付费执行的分支。检查清单的内容（可解析输出、幂等性）是必要的，但不是实际问题。问题是抽象层级。人类学习一次资源层次结构。代理每次都从意图出发，不应该重新推导你的领域模型来表达它。我尝试的方法是——三层结构，代理根据任务适合进入其中一层：知识层：技能、模式、文档——存在什么以及如何运作；意图层：运行、部署、验证——高级操作，在底层解析输入类型；状态层：执行、工件、实例——真实的对象，用于检查和恢复。常规工作进入意图层。调试和恢复下降到状态层。67个命令缩减为：loomloom run quote <work> loomloom run start <work> loomloom run watch <run-id> loomloom run results <run-id> 支撑它的原则是：辅助意图，以钱包为门控。系统免费进行安全推断——解析类型、格式化输入。它在花费金钱或修改远程状态之前会停止并询问。幂等性意味着操作可重试；这并不意味着代理应该自动重试。在批量规模下，自动重试会增加成本，所以安全 ≠ 自动。一个具体流程：意图 → 报价 → 明确批准 → 开始 → 观看 → 结果 我仍然卡住的地方，以及我希望从那些观察过代理运行真实软件的人那里得到输入的地方：你在哪里划定意图/资源边界，而不让意图表面扩展到40个定制动词？你如何测试CLI是否真的对代理更容易——而不是只对我更容易描述？在批量规模下，什么补救策略考虑总成本而非每项任务的安全性？相同的意图模型应该跨CLI、API和MCP共享，还是它们各自需要不同的形状？这些建议尚未定论——很高兴有人告诉我CLI设计师在20年前就已经解决了哪些问题。