ZGI Workspace：统一组织 Agent 资源

Agent 数量增加后，最先失控的往往是资源关系。同一份制度被复制进多个知识库，同一个工具出现几套参数，模型切换后只有部分流程完成更新。Workspace 用一个明确范围组织 Agent 依赖的模型、知识、数据库、Skills 和 Workflow，并把权限、发布与运行记录接到这套关系上。

ZGI 把这些能力放在一个可自托管的 Agent Runtime 工作区中。团队可以为 Agent 绑定批准的知识、数据库、Skills 和 Workflow，再通过工作区权限控制谁能配置、使用和查看相关资源。工作区提供共同边界，资源之间的依赖仍需设计者明确维护。

资源散落会产生隐蔽版本差异

单个 Agent 可以靠人工记住配置，十几个 Agent 很快就会出现"看起来一样，实际不同"。客服与销售各复制一份产品资料，其中一份完成更新，另一份仍然引用旧内容；两个流程调用同名 Skill，却使用不同字段；模型凭据散落在多个项目，切换供应商时难以判断影响范围。

整理工作区时，应先记录每个 Agent 依赖什么，再决定哪些资源共享、哪些保持独立。共享能够减少重复维护，独立可以隔开部门数据和高风险动作。选择依据来自业务边界，不能只看资源名称是否相同。

把资源集中到一个页面，只解决了查找问题。真正有用的 Workspace 还要能回答：某个知识库被哪些 Agent 使用，一项 Skill 由哪些 Workflow 调用，模型路由变化会影响哪些线上入口。缺少依赖关系，修改仍然只能靠经验判断。

可以从三类信息开始记录。第一类是所有者，明确谁负责更新和验收；第二类是使用范围，写清部门、项目和 Agent；第三类是版本与状态，区分草稿、测试和正在使用的配置。发生变更时，先找到直接依赖，再运行相关样本和固定回归任务。

工作区成员能够看到某个 Agent，不代表该 Agent 可以读取全部数据。用户身份需要继续传到知识检索、数据库和工具调用环节。公共高权限凭据会绕开原有业务限制，也让运行日志难以说明动作代表谁完成。

在 ZGI 中组织资源时，可以分别检查工作区成员权限、Agent 使用权限、知识与数据库范围、Skill 允许动作，以及 Workflow 中的审批节点。权限边界越接近真实业务对象，后续排查越容易定位。

工作区治理不必一次覆盖全部 Agent。先选一个跨知识、工具和流程的真实任务，列出资源清单，删除重复副本，标记所有者和使用范围，再用几条常见任务、越权请求和失败输入做验收。运行结果稳定后，把同样的方法扩展到下一个场景。

ZGI Workspace 适合承接这套整理，因为 Agent、模型、知识、数据库、Skills、Workflow 与运行治理可以放在同一范围内。最终效果仍取决于资源边界、权限和测试是否写清。Workspace 让这些关系能够被看见，也给持续维护留下统一入口。