管理员配置

管理员负责让平台可用、可控、可追踪。首次部署后，建议按“账号、模型、系统配置、通知、成本、资源入口”的顺序检查。

管理员不需要替用户完成每一次任务，但需要保证用户发起任务时不会因为账号、模型、能力、密钥、对象存储或通知渠道缺失而卡住。

管理员入口

管理员可从侧边栏或用户菜单进入后台管理。普通用户不会看到完整后台入口。

后台常用模块：

界面主题

管理员可在“系统配置 → 通用设置”中选择用户端界面主题：

• 当前主题：默认选项，保持原有配色。
• New Steel：使用 New Steel Light/Dark 语义 Token。

主题配置保存后无需重新构建或重启服务。当前管理页面会立即应用新主题，其他已经打开的页面在刷新后生效。用户仍可独立选择浅色或深色模式，管理员主题不会覆盖个人明暗偏好。

开发或验收新主题时，遵循主题系统与前端配色开发手册和主题视觉验收与踩坑手册，不要在业务页面中逐项覆盖颜色。

办公首页人物图

管理员可在“系统配置 → 通用设置”中选择办公首页人物图。默认使用静态机器人插画，不提供悬停动画；如需恢复原人物及悬停动画，可切换为“动态人物（悬停动画）”。配置保存后无需重新构建或重启服务，其他已经打开的页面在刷新后生效。

上线前检查清单

1. 用户账号可登录，管理员账号权限正确。
2. 模型配置可用，默认模型符合预期。
3. Backend、Executor Manager、Executor 和对象存储都可访问。
4. 通知渠道至少有一个可用配置。
5. API 访问和 WebHook 权限符合团队安全要求。
6. 资源菜单只放可靠链接，避免无效入口。
7. 成本看板能正常展示 Token 和费用。
8. 文档入口可访问，培训材料已准备。

建议上线前准备三条样例数据：

1. 一个示例 Agent，用于演示固定场景任务。
2. 一个示例定时任务，用于演示自动化和通知。
3. 一个示例发布页，用于演示产物沉淀。

模型配置

模型配置影响用户任务的执行质量和成本。建议：

• 明确默认模型。
• 区分高质量模型和低成本模型。
• 按业务、办公场景分别维护全局、团队或用户的有序可切换列表，优先级为用户、团队、全局、原模型列表。
• 单独配置的列表第一项自动作为该范围默认；如需恢复继承，应关闭“单独配置模型列表”，不要保存空列表。
• 对测试环境使用更低成本配置。
• 按配置决定是否启用工具搜索；新增配置默认开启。
• 按配置决定是否开启实验性功能；新增配置默认关闭。
• 记录模型变更原因，避免用户感知突然变化。

如果任务质量明显下降，优先检查近期模型配置是否变更。

模型配置变更建议记录：

• 变更时间。
• 变更前后模型。
• 影响范围。
• 变更原因。
• 回滚方式。

系统环境变量

管理员可维护系统级变量模板，用户再填自己的个人值。适合这种变量：

GITHUB_TOKEN：访问代码托管平台
JIRA_TOKEN：访问需求管理系统
INTERNAL_API_BASE_URL：内部服务地址

不要把所有用户共享的敏感密钥随意暴露给普通用户。能按用户隔离的密钥，优先让用户配置个人变量。

如果某个 MCP 需要 ${VAR} 形式的变量占位，管理员应在系统模板里写清楚变量用途，用户再在个人环境变量里保存自己的值。不要要求用户把密钥粘贴到任务对话里。

能力治理

Skills、MCP、专家、插件、Subagents 是用户执行任务时最容易影响稳定性的能力。建议管理员定期检查：

• 是否存在无人维护但仍启用的 MCP。
• 是否有重复或命名不清的 Skills。
• 专家模板是否通过兼容性检查后再发布。
• 用户专家是否仍绑定定时任务，避免直接停用或删除。
• 插件是否经过测试后再开放给团队。
• Subagents 是否真的服务可复用子任务。
• 系统级能力是否只开放给有权限的用户。

能力治理的目标不是限制用户，而是减少“能力太多导致任务误用工具”的情况。

“专家管理”分为两类数据：专家模板用于专家市场分发；用户专家是用户实际运行的 Agent，可能来自工作台创建、模板安装或分享导入。下架模板不会影响已有用户专家，但已有历史用户专家引用时不能删除模板。

首页内容

“首页内容”用于维护办公场景首页输入框下方的快捷入口和最佳实践卡片。管理员可以配置中英文标题、提示词、图标、语义色、排序和启用状态；最佳实践还支持说明、分类与使用次数。

颜色保存为 primary、info、success、warning、neutral 等语义值，由当前主题转换为实际颜色。不要用固定色值替代语义色，否则会破坏浅色、深色和不同主题之间的兼容性。

数据库迁移会写入首批默认内容。后续新增、编辑、停用或删除内容都通过“首页内容”管理，不需要修改或重新构建前端代码。

通知配置

系统级通知用于管理员维护通用渠道，例如邮箱 SMTP。用户侧是否接收通知，通常还需要在具体任务或个人配置中开启。

建议至少测试：

1. 保存配置。
2. 测试发送。
3. 定时任务失败通知。
4. 长任务完成通知。

通知渠道和 WebHook 不要混用。通知用于提醒人，WebHook 用于通知系统。生产环境建议给 WebHook 配置签名密钥，并要求接收端做幂等处理。

资源菜单

资源菜单会出现在侧边栏“资源”分组，适合放：

• 内部使用手册。
• Skills 创作指南。
• 团队规范。
• 工单系统。
• 监控看板。

资源菜单不是公告栏。链接太多会降低使用效率，建议只放高频入口。

成本与审计

成本看板用于观察整体费用、用户排行、会话排行和活跃趋势。建议定期检查：

• 是否有异常高成本用户。
• 是否有失败但高消耗的会话。
• 是否有大量夜间任务。
• 是否有不再使用但仍启用的定时任务。

排查成本异常时，先从会话排行定位高消耗任务，再看工具调用和失败原因。不要只看总 Token，失败重试、浏览器任务、外部工具超时都可能导致成本上升。

使用技巧

• 新用户培训前，先准备 1 个示例 Agent、1 个示例定时任务和 1 个示例发布页。
• 每次开启新能力后，都补充一条简短内部说明。
• 管理员不要直接替用户保存个人密钥，除非团队已有明确安全流程。
• 发现成本异常时，先查会话排行，再看对应工具调用和模型配置。
• 上线后第一周建议每天检查失败任务、通知投递和对象存储导出情况。
• 新增或下线环境变量时，同步更新配置文档，避免用户任务运行时才失败。