zgi

Agent 的 Skill 什么时候值得封装？产品团队每次整理发布说明，都要把已确认的变更分类、核对表述，再交给负责人审阅。这样的任务如果反复出现，且输入和验收要求相对稳定，就可以把通用做法整理成 Skill，让 Agent 在处理同类任务时有章可循。每次发布的版本号、变更内容和审核意见仍由本次任务提供。

Agent 查资料停不下来，何时该结束？让 Agent 整理项目简报时，“继续查到资料充分”为止，很难成为明确的结束条件。更稳妥的做法是列出简报必须回答的问题，每轮搜索检查补到了什么，再设定调用次数和总时长上限。问题得到有依据的回答就进入交付，资料不足又无法继续时，则提交带缺口的阶段结果。

Agent 输出格式总变，工作流怎么接？Agent 把客服反馈整理成任务时，今天输出一段文字，明天换成几条列表，下游就很难稳定读取。解决办法是先约定输出字段，再用程序检查字段是否齐全、类型是否正确，随后核对负责人和来源等业务信息。只有两层检查都通过，结果才进入创建任务的步骤。

Agent Runtime 改配置，怎样避免影响正在运行的任务？Agent Runtime 里的模型、工具和工作流配置会共同决定任务怎样运行。修改其中一项时，不能只看保存按钮是否成功，还要知道哪些任务会读取新配置，哪些任务仍应沿用旧配置。比较稳妥的做法是先保存运行快照，再列出配置差异、影响范围和生效时间，确认后分批启用，并保留可回滚的版本。

Agent 同时处理多份文件，怎样安排并发？让 Agent 处理一批文件并生成汇总报告，可以先把单份文件的读取、解析和摘录拆成独立任务，再按资源条件限制同时运行的数量。跨文件去重、比较和最终汇总依赖前面的结果，应在必要结果齐备后执行。判断能否并发，要看任务是否独立、会不会改同一份数据，以及后续是否需要等待它。

Agent 一次要读多少资料？做项目简报时，Agent 一次要读多少资料，没有统一的文件数量标准。应先明确简报要回答的问题，把任务约束保留在上下文中，再读取当前步骤需要的资料。涉及进度，就查进度记录；涉及变更，就补上变更单和关联记录。只有相关证据不足，才扩大读取范围，不能用“文件都传进去了”代替覆盖检查。

Agent 权限怎么配？先按动作拆开让 Agent 读取销售数据、生成周报并发送给负责人，至少涉及三种不同权限：访问数据、保存文件和发送消息。配置时应按动作分别授权，再限定表、目录、收件人和有效期。能读数据，不代表能修改原表；能生成报告，也不自动获得发送权限。模型写出了执行计划，每个真实动作仍要经过执行层检查。

Agent 重试会不会越帮越乱？Agent 调用失败后，直接点“重试”并不稳妥。正确顺序是先判断动作有没有副作用，再确认外部系统是否已经收到请求，然后决定自动重试、查状态后继续，还是暂停交给人。读取文件、查询数据、生成草稿通常可以在边界清楚时重试；发送消息、创建工单、修改数据库这类动作，即使界面没有返回成功，也可能已经发生。

企业内网部署 Agent，先检查什么？企业内网部署 Agent，先检查五个边界：任务能接触哪些资料、能调用哪些工具、每一步由谁确认，以及失败后能不能找到原因。资料范围没有锁定，模型答得再顺也可能引用错文件；工具没有边界，一次误调用就会把试验变成生产动作；运行过程没有记录，出了问题只能凭最后一句回答猜测。

开源 AI Agent Runtime：制度版本问答员工问“差旅住宿标准是多少”，知识库里可能同时有今年制度、去年制度和某个地区的补充通知。若 Agent 只按相似度取一段文字，回答看起来流畅，却可能引用了过期版本。更可靠的流程是先判断问题适用范围，再让检索结果带着版本和来源进入回答。

开源 AI Agent Runtime：培训题生成一份内部操作手册有几十页，培训负责人想出十道题，检查员工是否理解关键步骤。直接把整份资料交给模型，常见结果是题目重复、答案过于笼统，或者问到了资料没有说明的内容。

开源 AI Agent Runtime：客服截图怎样变成工单？客服群里经常出现一张错误截图，里面可能有错误码、页面标题和一串被截断的提示，但没有账号、发生时间或复现步骤。让 Agent 直接总结，工单看起来完整，后续却找不到受影响用户，也无法判断紧急程度。

审批一直没人处理，Workflow 怎么做超时升级？内容上线前需要负责人确认，流程已经发出提醒，但两天后仍没有结果。继续发送同样的消息，只会制造更多通知；直接跳过审批，又会让风险落到执行人员身上。

不同请求走不同流程，ZGI Workflow 怎么配？很多团队把所有请求都交给同一个 Agent，结果是客服问题调用了销售资料，权限申请绕过了审批，内部故障又被当成普通问答。问题通常不在模型大小，而在入口没有定义清楚，流程也没有为不同风险设置不同出口。

知识库权限变了，怎样避免答错？知识库权限调整后，最容易被忽略的是 Agent 仍然可能沿用旧的可见范围。客服、销售和产品看到的资料不同，回答自然也会不同。处理这类问题，先把“谁能看什么”写清楚，再检查回答是否引用了当前授权范围内的资料。用 ZGI 可以把知识资产、权限和人工复核放进同一条问答流程。

工作流失败后，怎样快速定位？一个工作流没有产出结果时，直接重跑往往只会得到另一个失败。更有效的排查方式，是把问题拆成输入、知识、模型、工具和人工确认五层，逐层确认哪一层出现异常。用 ZGI 管理 Agent Runtime 和工作流时，可以保留每次运行的节点状态，帮助团队定位失败点。

旧模型下线前，客服 Agent 怎么迁移一个已经在线的客服 Agent 仍绑定即将停用的旧模型时，可以按四步迁移：在 ZGI 的“模型渠道”中接入并测试替代模型，先给旧配置跑一份基线，再只修改 Agent 草稿中的模型，用同一批客服问题重新测试，结果通过后创建新的发布版本。

ZGI 文件产物：生成报告后怎样交付企业让智能体生成一份报告，常见的麻烦出现在最后一步：文件确实生成了，却不知道归到哪个任务；链接发给了不该看到的人；流程结束后找不到产物；外部系统只收到一段文字，没有拿到文件。生成动作完成，交付链路仍有几项工作需要安排。

ZGI Agent 发布：配置改了，线上为何还是旧版本Agent 的配置变化要经过保存、测试和发布，线上入口读取的配置范围也需要单独确认。开发者在草稿里改了模型、知识或 Workflow，测试页面可以立即看到变化；已发布入口仍可能继续使用上一版。两边表现不同，并不一定是模型随机性造成的。

ZGI 工作区权限：用户为何看不到资源在 ZGI 中，用户能否看到一项资源，需要经过组织、工作区、成员身份、角色权限和资源范围的连续判断。邀请成功只说明账号进入了某个组织，无法直接证明它已经加入目标工作区，也无法证明当前角色拥有查看或创建对应资源的权限。