ZGI 发布治理：同一个 Agent 服务多个入口

同一个 Agent 服务多个入口时，可以共用指令、模型、知识、Skills 和 Workflow，把网页交互、内部使用、系统 API 与计划任务放在一套能力配置上。入口负责接收请求和返回结果，Agent Runtime 负责组织执行。身份、权限、输入格式和失败处理需要按入口分别设置。

ZGI 支持把 Agent 绑定到批准的知识、数据库、Skills 和 Workflow，再通过 WebApp、内部应用中心、API 或计划任务与内部调用提供服务。团队修改核心能力后，可以用同一批测试任务检查各入口，减少多个版本逐渐偏离的情况。

共用的是能力配置

一个客服 Agent 可能同时出现在员工网页、内部应用和业务系统中。知识范围、订单查询 Skill、退款 Workflow 和模型设置可以保持一致，避免三个团队分别维护提示词与工具定义。更新制度资料或调整流程后，统一配置更容易控制影响范围。

共用配置不代表所有入口拥有相同交互。WebApp 可以让用户上传文件和连续追问，API 更关注固定字段与状态码，计划任务没有实时用户，需要提前定义输入来源和失败通知。入口差异应留在接入层，核心业务步骤放在 Agent 与 Workflow 中维护。

网页用户、内部成员、API 调用方和后台任务代表的身份不同。请求进入 Agent 后，身份信息要继续传到知识检索、数据库和工具调用环节。只在入口检查一次登录，后续节点使用公共高权限账号，会让原有边界失去作用。

API key 可以识别调用方，无法自动说明调用方有权读取哪些订单或修改哪些记录。执行节点仍需结合用户、部门、项目和业务对象判断。计划任务也要指定服务身份，并限制它能访问的数据和工具。

WebApp 允许自然语言输入，系统可以追问缺失信息；API 调用通常需要稳定字段，缺少参数时直接返回明确错误。计划任务的输入来自数据库、文件或上游流程，运行前要检查数据是否到齐。把所有入口都当成聊天窗口，会给系统集成增加不确定性。

输出也要分开处理。网页可以显示解释与引用，API 应返回结构化字段、任务编号和状态，后台任务需要保存回执并发送异常通知。核心 Workflow 可以共用，入口适配层负责把同一执行结果转换成合适格式。

每次修改 Agent 配置后，至少为各入口运行一条相同业务任务，比较调用的知识范围、工具参数、流程节点和最终业务状态。随后再测试入口特有能力，例如 WebApp 文件上传、API 缺少字段、内部成员权限和计划任务超时。

ZGI 的运行日志和批量测试可以用于关联入口、Agent 配置与执行结果。实际验收时还要使用企业自己的账号、数据和接口规则。同一个 Agent 能减少重复维护，各入口的独立边界仍需被明确测试和记录。