用 Agent 建一个 3D 模型，过程可能和想象完全不同：Blender 的界面上毫无动静，一直停在欢迎页面，Agent 在旁边持续写代码——它用的是 bpy，Blender 自带的 Python 接口。过一会儿它说建好了，打开一看，模型已经完成。整个过程对图形界面的依赖，只剩最后打开文件确认结果。
这个案例值得仔细拆解，因为它展示了软件真正“被 Agent 用起来”时发生的事情：操作不走界面，走的是软件暴露的编程接口；结果可以被检查，闭环才能成立。
界面不是给 Agent 的入口
图形界面为人设计，靠可视化和即时反馈帮助人理解状态。Agent 更高效的路径是绕过这层，直接调用接口。一条兜底路线是 Computer Use：模型厂商等不及软件逐个改造，先训练模型去操作人类界面，让它能使用以前的软件。软件自己主动适配是另一条路线，两条并行推进。但只要软件开放了接口，操作界面就只是过渡形态——每次点击背后本来就是一个可调用的能力。
通过接口操作还有效率上的差别。用 bpy 建模几乎不消耗“看界面”的开销，Token 效率高，中间用 MCP 截图确认的次数也很少。Godot 等游戏引擎有类似的结构：做完直接打开就有结果，不存在一个“操作界面”的过程。
这提示了一种分工：让代码负责操作，让界面负责查看。软件可以继续把交互打磨得对人友好，同时为 Agent 的调用效率单独做一套基建——两条通路服务两类使用者，不必互相迁就。
能力接口与可检查的结果
软件对 Agent 的可用性，第一个标准是它暴露了哪些能力接口。命令行工具天然占优：剪辑工作流里，Codex 加 FFmpeg 可以直接完成剪辑——不是因为它操作了某个剪辑软件的界面，而是 FFmpeg 本身就是一套文本接口。相比之下，图形软件如果没有开放接口，同样的工作流就接不进去，无论它的界面做得多么完善。这与某款软件好不好用无关，只是接口开放程度的差别。
第二个标准是结果可检查。Agent 的产出要能被验证，任务才算闭环：模型建好了，打开文件确认；排版生成了，截图比对。可检查性决定了 Agent 能否自我修正，也决定了人需要在哪些节点介入。
内置 Agent 与开放能力是两回事
软件拥抱 Agent 有两种方式，经常被混为一谈。第一种是把 Agent 装进自己的软件：内置一个助手，改善自家产品的体验。剪辑软件出自己的 Agent 属于这一类。第二种是把软件的能力开放出来，让外部 Agent 调用。
两者的差别在封闭性上最明显。一个剪辑软件的案例是：它有类似 Skill 的能力体系，但录制那次讨论时只能用在自己家的 Agent 里，外部的 Codex 调不了。能力是有的，只是锁在自家生态里。另一种做法是 DaVinci Resolve 把能力拆成 MCP，任何模型都能接；当时它还把 MCP 放在付费版里——开放本身成了付费点，说明软件厂商开始把“能被 Agent 调用”当成一种可以定价的能力。
两种方式回答的是不同问题：内置助手服务于自家软件的用户，开放能力让软件进入别人的工作流。对使用多种 Agent 的用户来说，第二种决定了这款软件能不能出现在自己的任务链里。
宿主也要接得住
软件开放了能力，还需要宿主 Agent 有执行环境承接，这一环同样经常缺失。垂类设计 Agent 的反例：接的模型明明有编码能力，产品却主动限制编程；排版的参考图能上传、Agent 也能看到文件夹里有它，真要调用时却调不了——文件系统支持不完整。即使建模软件开放了 bpy，这样的宿主也用不上。临时的虚拟机还带来持久化问题：每次拉起的是不同环境，上下文难以延续。
软件成为 Agent 插件
把两条线索合起来，可以得到一个方向性的说法：原来的模式是软件把 Agent 弄进来，接下来的模式是软件把自己变成 Agent 插件——不再等某个内置助手，而是让自己的能力成为所有 Agent 都能调用的工具。围绕这个方向已经有产品设想，比如为封闭生态的剪辑软件做一个支持外部 Agent 调用的替代品；设想是否成立，要看它能否回答前面列出的三个问题：能力接口是否完整、结果是否可检查、宿主环境是否接得住。
这三条也构成评估任何一款软件“Agent 可用性”的清单。三条都满足，软件才不只是给人用的界面，而是 Agent 工作流里真正用得上的工具。