这和给 Agent 一个 API key 不同。API 只暴露一组固定调用；应用暴露的是工作界面：屏幕显示什么、有哪些数据、当前状态是什么、下一步能做什么。
API、插件与 App for Agent
| API | 插件 / 工具 | App for Agent | |
|---|---|---|---|
| Agent 得到什么 | 一组接口 | 一项新增能力 | 界面、数据、状态和操作 |
| 能看到当前界面吗 | 不能 | 不能 | 能，如果读取渲染结构 |
| 能决定下一步吗 | 只在接口范围内 | 只在工具范围内 | 在权限范围内可以 |
| 谁维护接入 | 开发者 | 插件作者 | Space 与 Agent 一起 |
| 典型失败 | 调错接口或缺少上下文 | 工具太窄 | 界面或状态不可读 |
API 仍然有用，插件也仍然有用。问题在于 Agent 是否有足够上下文把它们用好。对窄任务来说，一次 API 调用可能就够了；对发生在界面里、有数据和状态的工作来说，面向 Agent 的应用更合适。
为什么 Agent 需要工作界面
当 Agent 看不到工作时，失败方式很固定：
- 猜当前状态，基于过期信息行动。
- 调用的工具和屏幕显示的内容不匹配。
- 做完一步，却判断不了是否成功。
- 需要人替它在界面和任务之间翻译。
暴露工作界面能解决大部分问题。Agent 可以读取当前视图、检查数据、执行操作并验证结果；人仍然可以在同一个界面里复核。
Sigla 如何构建 App for Agent
在 Sigla 里，AI Agent Space 既是应用，也是 Agent 的工作环境。Space 承载界面、数据、文件、逻辑和已接入的能力。MCL 是 Sigla 的 AI Native 框架，把这一切表达成同一份代码。这份代码就是 Agent 读取的上下文。
这带来三个结果：
- Agent 能看到应用做什么、状态在哪里。
- 修改发生在运行应用的同一套结构里。
- 结果可以同时供人和 Agent 使用。
这就是「为 Agent 而生的应用，而不是需要你维护的代码」在实际中的含义。你交付的不是一个要交给集成团队的代码库，而是一个 Agent 能读取、修改和操作的 Space。
常见问题
App for Agent 就是 API 吗？
不是。API 暴露调用；App for Agent 暴露工作界面：界面、数据、状态和操作。两者都能被 Agent 使用，但提供的上下文不同。
我需要为 Agent 单独做一个应用吗？
不一定。如果工作都在一个 Space 里完成，同一个 Space 可以同时服务人和 Agent。当 Agent 需要更窄或更安全的界面时，单独做应用才有必要。
Agent 能使用不是为它设计的应用吗？
有时可以，通过 computer use 或浏览器自动化。但通常比结构可读的软件更慢、更不可靠。所以「Agent 可用」是设计选择，不只是运行时技巧。