Agent 数量增加后，最先失控的往往是资源关系。同一份制度被复制进多个知识库，同一个工具出现几套参数，模型切换后只有部分流程完成更新。Workspace 用一个明确范围组织 Agent 依赖的模型、知识、数据库、Skills 和 Workflow，并把权限、发布与运行记录接到这套关系上。
ZGI 把这些能力放在一个可自托管的 Agent Runtime 工作区中。团队可以为 Agent 绑定批准的知识、数据库、Skills 和 Workflow，再通过工作区权限控制谁能配置、使用和查看相关资源。工作区提供共同边界，资源之间的依赖仍需设计者明确维护。
资源散落会产生隐蔽版本差异
单个 Agent 可以靠人工记住配置，十几个 Agent 很快就会出现"看起来一样，实际不同"。客服与销售各复制一份产品资料，其中一份完成更新，另一份仍然引用旧内容；两个流程调用同名 Skill，却使用不同字段；模型凭据散落在多个项目，切换供应商时难以判断影响范围。
整理工作区时，应先记录每个 Agent 依赖什么，再决定哪些资源共享、哪些保持独立。共享能够减少重复维护，独立可以隔开部门数据和高风险动作。选择依据来自业务边界，不能只看资源名称是否相同。
| 资源 | 工作区内需要记录 | 变更时重点检查 |
|---|---|---|
| 模型 | 默认模型、路由与凭据范围 | 输出结构、成本与超时 |
| 知识 | 数据来源、更新人与可见范围 | 旧内容、引用与权限过滤 |
| Skill | 输入输出、依赖和允许动作 | 参数兼容与业务副作用 |
| Workflow | 节点、分支、审批和状态 | 中断恢复与失败路径 |
| Agent | 指令、记忆与资源绑定 | 各入口的实际结果 |
共享资源需要留下依赖关系
把资源集中到一个页面，只解决了查找问题。真正有用的 Workspace 还要能回答：某个知识库被哪些 Agent 使用，一项 Skill 由哪些 Workflow 调用，模型路由变化会影响哪些线上入口。缺少依赖关系，修改仍然只能靠经验判断。
可以从三类信息开始记录。第一类是所有者，明确谁负责更新和验收；第二类是使用范围，写清部门、项目和 Agent；第三类是版本与状态，区分草稿、测试和正在使用的配置。发生变更时，先找到直接依赖，再运行相关样本和固定回归任务。
权限应跟着请求进入后续节点
工作区成员能够看到某个 Agent，不代表该 Agent 可以读取全部数据。用户身份需要继续传到知识检索、数据库和工具调用环节。公共高权限凭据会绕开原有业务限制，也让运行日志难以说明动作代表谁完成。
在 ZGI 中组织资源时，可以分别检查工作区成员权限、Agent 使用权限、知识与数据库范围、Skill 允许动作，以及 Workflow 中的审批节点。权限边界越接近真实业务对象，后续排查越容易定位。
从一个业务场景开始整理
工作区治理不必一次覆盖全部 Agent。先选一个跨知识、工具和流程的真实任务，列出资源清单，删除重复副本，标记所有者和使用范围，再用几条常见任务、越权请求和失败输入做验收。运行结果稳定后，把同样的方法扩展到下一个场景。
ZGI Workspace 适合承接这套整理，因为 Agent、模型、知识、数据库、Skills、Workflow 与运行治理可以放在同一范围内。最终效果仍取决于资源边界、权限和测试是否写清。Workspace 让这些关系能够被看见，也给持续维护留下统一入口。
GitHub：https://github.com/zgiai/zgi