截图里有信息，不等于可以直接建单
客服群里经常出现一张错误截图，里面可能有错误码、页面标题和一串被截断的提示，但没有账号、发生时间或复现步骤。让 Agent 直接总结，工单看起来完整，后续却找不到受影响用户，也无法判断紧急程度。
这类请求适合分成三步：先提取截图中确实存在的文字，再检查业务字段是否齐全，最后把缺失项发回客服或客户补充。图片解析负责"看到了什么"，Workflow 负责"还缺什么"，工单工具负责"什么时候可以创建"。
ZGI 可以组合文件输入、Agent、结构化输出和 Workflow。Agent 做 OCR 后的语义整理，流程节点保存原图和解析文本，校验节点检查字段，人工确认节点决定是否提交工单。任何一步失败，都要留下原始输入和失败原因。
一条可执行的处理路径
可以先用十张脱敏截图验证：
-
上传截图并生成附件编号，记录来源和接收时间。
-
提取错误码、页面、提示文字和可识别的版本信息，无法识别的字段留空。
-
检查账号、发生时间、影响范围、复现步骤四项是否齐全。
-
信息足够时生成工单草稿；信息不足时输出待补问题，不调用创建接口。
-
客服确认草稿后再提交，并把工单编号回写到原会话。
| 字段 | 解析来源 | 缺失动作 |
|---|---|---|
| 错误码 | 截图文字 | 标记待确认 |
| 账号 | 会话或客服补充 | 追问 |
| 发生时间 | 会话时间或客户补充 | 追问 |
| 影响范围 | 客服判断 | 人工确认 |
让输出能被下一个节点接住
Agent 输出不要只要一段自然语言。可以固定为 error_code、page、account、occurred_at、impact_scope、reproduction、evidence_file 和 missing_fields。工单节点只读取通过校验的字段，截图和原始解析文本作为附件保留。
如果一张截图里出现多个错误码，输出应保留数组和对应位置，不能只挑一个"看起来最重要"的错误。页面名称也要和产品模块映射，但映射表需要由团队维护。
测试时要故意加入模糊截图、多个错误码、截图与文字描述不一致、没有账号四类样本。检查流程是否保留原图、是否明确标出不确定内容、是否在字段不足时停止创建。通过后再接入真实客服入口。
这和只接一个模型有什么区别
如果只是调用一个模型接口，团队还要自己处理文件上传、上下文拼接、工具权限、失败重试、任务状态和日志。模型可能能读懂截图，但没有地方保存原始附件，也没有统一机制阻止它在字段不完整时创建工单。Runtime 把这些执行环节放到同一层，让 Agent 的回答、工具调用和工作流节点有共同的运行上下文。
以开源 AI Agent Runtime 为例，开发者可以在自己的环境中组合模型、知识、文件、工具、技能和 Workflow，再把 Agent 暴露为 WebApp、API 或内部入口。开源的价值不在于"模型自动变聪明"，而在于团队可以看清任务如何运行，按自己的数据、网络和权限边界调整组件。具体可用节点仍要以实际版本和部署配置为准，不能把架构图当成已完成的业务集成。
从本地验证到业务接入
第一步只跑离线样本：准备脱敏截图和期望字段，观察解析结果是否稳定。第二步接入一个只读工单草稿接口，禁止直接提交；第三步再加入人工确认和真实创建接口。每一步都保留输入文件、结构化输出、工具响应和运行状态，出现错误时可以回放，而不是重新猜模型当时做了什么。
部署开源 Runtime 时，还要明确哪些组件放在内网，哪些请求可以出网，模型凭据由谁管理，上传文件保留多久，Runner 和 Sandbox 是否需要隔离。客服场景涉及客户账号时，权限校验应由业务服务完成，Runtime 只执行已经定义好的授权路径。这样扩展到邮件、知识检索或报表任务时，仍然能复用同一套运行边界。
一份可执行的验收清单
检查 Agent 是否能接收文件并保留附件编号；检查结构化输出是否能被下一节点读取；检查字段缺失时是否追问而不是补猜；检查工具失败时是否记录错误码；检查人工确认前是否不会创建真实工单；检查运行日志能否按请求 ID 找回完整链路。六项通过，才适合把这条流程交给更多客服使用。
GitHub：https://github.com/zgiai/zgi