03 · AI Operator
服务于人的自动化。
用于跨多个运行环境编排 AI 智能体的内部操作工具集，提供统一的控制界面。
挑战
问题所在。
智能体任务很少只使用一种语言或一个运行环境。缺少统一的操作层时，团队需要为每个界面重复构建启动、停止、检查和路由等控制功能。
我们需要的是一套在运行环境不断增加时仍清晰易用的工具，而不是一堆一次性脚本。
方法
我们的应对方法。
01
统一操作界面
运行环境的差异由底层处理，操作人员通过一致的界面开展工作。
02
从设计之初采用多种编程语言
Python 核心、TypeScript 界面、Go 服务及原生客户端，各用于最适合的场景。
03
默认具备可观测性
无需为每个进程连接调试器，即可查看运行、失败及任务交接情况。
04
优先满足内部需求
首先为我们自己的操作人员构建，重视清晰易用，减少繁琐形式。
我们构建的内容
我们的交付成果。
编排核心
通过统一的控制路径，协调 Python 及相关运行环境中的智能体运行。
操作界面
使用 TypeScript 界面进行日常检查、路由与控制。
服务层
通过 Go 服务处理性能敏感路径与共享 API。
原生客户端
使用 Swift 客户端承载需要在设备上运行的操作流程。
内部文档
提供操作手册与演示资料，使原作者之外的人员也能持续使用这套工具。
架构
系统概览。
采用多语言单一代码仓库：Python 用于智能体核心，TypeScript 用于操作界面与工具，Go 用于服务端点，Swift 用于原生客户端。
统一的配置与日志约定，使技术栈在加入新运行环境时仍便于运维。
数据与事实
概览。
Python · TS · Go · Swift
语言
内部操作人员
主要面向
跨运行环境智能体
范围
正在开发中
状态
我们的经验
带入后续工作的经验。
- 01
统一的操作术语比完美的抽象更重要，团队需要在各处使用一致的操作名称。
- 02
采用多种编程语言只有在边界明确时才有价值，否则只会成为四套半成品技术栈。
- 03
将文档视为产品的一部分，而非留待最后的任务，内部工具才能发挥作用。
下一步
下一步。
- 改进运行检查与失败智能体执行路径的重放功能。
- 根据生产任务的需求扩展运行环境覆盖范围。
- 随着更多团队共用操作界面，进一步强化访问控制。
继续交流