AI：Auto 体系中的共享能力与工作工具
AI 参与了 Auto 的开发，也正在成为应用可以接入的系统能力。当前建设集中在共享模型服务、Agent 执行与开发工具；长期方向是让 AI 与语言、桌面和应用共同服务于人的知识管理和工作生活。
当前进展说明 · 2026-10-01
- 应用与用户界面 · 任务、结果和确认
- Agent 与工具 · 角色、技能和操作
- 共享客户端 · 请求与响应
- aaid 模型服务 · 接入、并发、路由与用量
- 已配置的模型提供商
为什么放在系统层
多个应用使用模型时，会遇到相同的问题：连接哪个提供商、如何配置模型与密钥、如何控制并发、如何查看用量。AutoAI 将这些公共能力放到共享服务中，让接入的应用专注于自己的任务。
这种组织方式也使 AI 能力不局限于某一个聊天界面：命令 Shell、开发工具以及后续知识应用可以复用相同基础设施。各应用按自己的任务和工具逐步接入。
应用、Agent 与服务的关系
| 层次 | 当前职责 |
|---|---|
| 应用与用户界面 | 表达用户任务、呈现结果与进度，提供操作和确认入口 |
| Agent 执行层 | 组织角色、技能、工具调用与工作流 |
| 共享客户端 | 向模型服务发送统一请求、接收响应 |
aaid 模型服务 | 管理已配置提供商的接入、并发、路由与用量记录 |
| 配置服务 | 管理应用、角色、技能和模型配置 |
典型接入路径为“应用 → Agent/客户端 → aaid → 已配置的模型提供商”。工具执行发生在相应应用或 Agent 工具层，模型 Daemon 专注于模型通信与资源协调。
已有的应用与接入
- AutoMusk：开发工作工具，组织聊天、工具活动以及 Plan、Specs、Wiki 等项目材料。规划、执行、复核与知识沉淀分阶段进行，并保留人的确认环节。其实现结合 Auto 源码、生成代码与 Rust 基础设施。
- AutoAI CLI 与 AutoShell：提供终端中的 Agent 与 AI 交互入口。AutoAI CLI 的命令执行优先使用 AutoShell；执行失败与策略拒绝有明确的处理规则。
- 配置中心：管理角色、技能、应用和模型设置，使相关工具复用同一套配置入口。
各接入点的能力由自身工具与工作流决定，任务执行保留相应的人机协作与确认环节。
当前能力与边界
| 领域 | 当前能力与边界 |
|---|---|
| 模型接入 | 对已配置且有适配实现的提供商发送请求；可用模型取决于配置、凭据与提供商服务 |
| 请求协调 | 共享并发管理、模型路由和用量记录；路由遵循配置与候选规则，不保证自动选择“最佳模型” |
| Agent 工具 | 角色、技能、工具调用与工作流已有实现，具体能力由应用的接入和工具配置决定 |
| 系统集成 | 已有开发工具、Shell 与配置入口；跨应用知识协作和更完整的个人工作环境仍在建设 |
模型网关与命令执行、文件操作等工具是不同层次。界面应让人看清任务、状态、输出、验证结果和需要确认的操作。
从开发工具走向知识与工作环境
长期的 AI + Lang + OS 将把语言、系统服务和应用作为相互衔接的基础：用语言描述数据与操作，通过服务连接能力，在应用中保留知识、任务和工作成果。
这是长期产品方向。现有工具提供了部分基础，但统一的个人知识体系、跨应用长期协作与更广的工作生活场景，还需要明确的数据、权限和交互设计，并逐步实现。