用 ZGI 打造企业级 AI 智能体，可以从一个边界清楚的业务任务开始，将企业知识、模型、技能（Skills）、工具和工作流（Workflow）放进同一工作区，再补齐权限、审批、运行日志与失败处理。ZGI 提供可自托管的智能体运行时（Agent Runtime），适合把会回答问题的原型整理成能够持续执行、检查和复用的业务应用。
企业级并不取决于 Agent 接了多少模型。真正影响上线的，是它能读取哪些资料、允许调用哪些工具、任务中断后怎样继续、高风险动作由谁确认，以及发生错误后能否找到完整过程。用 ZGI 搭建时，可以按下面五层逐步推进。
概念示意图：企业 智能体 需要把业务任务、知识工具、 工作流 和运行治理连接起来。
先选一个能够验收的业务任务
第一步先写清任务的输入、输出和完成条件。以合同初审为例，输入包括合同文件、审查规则和业务背景；输出可以是风险条款清单、对应原文位置和处理建议；完成条件则由法务确认哪些结果可以直接进入下一步。
任务范围越清楚，后面的知识、工具和权限越容易配置。若一开始只写"做一个企业助手"，不同部门会不断加入新需求，Agent 的提示词和工具列表会迅速膨胀，也很难判断某次运行到底算不算完成。
把稳定知识和临时上下文分开
企业制度、产品资料、合同模板等长期内容可以进入知识库，需要时通过检索增强生成（Retrieval-Augmented Generation，RAG）查找。用户刚上传的文件、当前订单号和这次任务的限制条件，则留在本次上下文中。
在 ZGI 工作区中，可以为 Agent 绑定知识、文件输入、记忆和模型。资料接入后仍要用真实问题检查检索结果：正确段落是否进入候选、权限过滤是否准确、文档更新后旧内容是否仍被引用。知识库数量不能代替命中效果。
用 Skills 和工具承接实际动作
模型负责判断，外部动作需要交给边界明确的 Skills 或工具。查询数据库、生成文件、调用业务接口和执行计算，都应写清输入字段、允许动作、返回结构与失败信息。可重复使用的一类任务，可以整理成 Skill，避免不同 Agent 各自维护一套提示词和脚本。
ZGI 支持将文件、报告、计算、数据库和 Workflow 调用等能力封装为 Skills，并在隔离运行环境中执行。上线前要分别测试正常输入、缺失字段、超时和外部接口拒绝，确认工具失败时不会返回一个看似成功的自然语言答案。
| 层次 | 需要配置的内容 | 验收重点 |
|---|---|---|
| 业务任务 | 输入、输出、完成条件 | 结果能否被业务人员确认 |
| 知识与模型 | 资料范围、检索、模型选择 | 引用是否准确，权限是否生效 |
| Skills 与工具 | 参数、动作、返回结构 | 工具是否可控，失败是否清楚 |
| Workflow | 顺序、分支、等待、审批 | 中断后能否恢复，重复执行是否安全 |
| Runtime | 权限、日志、测试、发布 | 谁执行了什么，过程能否追踪 |
把业务规则放进 Workflow
当任务包含多步调用、条件分支或人工确认时，可以用 Workflow 固定执行路径。合同初审流程可以依次完成文件解析、规则检索、风险提取和结果整理；涉及高风险条款时进入人工审批，确认后再生成最终报告。
ZGI Workflow 支持模型调用、分支、循环、审批、用户问答、HTTP 请求、数据库操作和文档处理。流程设计时要为每个关键节点保留输入、输出和状态，遇到等待用户补充材料、审批拒绝或接口超时时，任务才能停在准确位置，而不会从头重复执行。
最后补齐运行和治理
正式上线前，至少准备三组测试：正常任务、信息不完整的任务和外部工具失败的任务。再用不同角色检查资料权限和工具权限，确认普通用户看不到越权内容，高风险动作会进入指定审批路径。
ZGI 可以通过 WebApp、应用中心、API 或内部调用发布 Agent，并用工作区权限、运行日志和批量测试观察发布后的表现。团队可以先选二十到五十条真实任务做小范围验证，记录完成率、人工接管位置和失败原因。等任务边界、执行路径和责任记录稳定后，再扩大使用范围。
GitHub：https://github.com/zgiai/zgi