演示服务台时，小林说“A301 投屏没有画面”。模型给出一段看似热心的回答：“先问连接方式，查一下设备说明；若不行，就创建工单。”这段话适合人阅读，却不适合程序直接执行：它同时包含追问、查询和写入三个动作，而且没有说明什么时候获得员工确认。企业 Agent 需要把“模型想做什么”变成可检查的数据。本文延续会议室求助故事，用结构化输出约束每轮只能提出一个候选动作，再由服务端判断该动作是否符合当前任务状态。示例使用 Python 标准库处理 JSON，不依赖特定模型服务；实际模型能否提供原生结构化输出，需要在接入时单独验证。文章目录自由文本为什么不能直接成为程序命令为每一轮决策规定一个小协议结构化决策的执行流程图用 Python 严格解析候选动作结构合法之后，还要做业务校验用反例验收协议的价值总结自由文本为什么不能直接成为程序命令当模型写出“我已经为你创建工单”，这句话既可能是对真实工具结果的总结，也可能只是语言生成。程序若通过搜索关键词“创建”来决定调用接口，便会把措辞当成授权；若从一整段自然语言里猜参数，还可能写错房间和故障现象。小林要的是可靠的处理过程，不是越来越像人工客服的口吻。模型自由表达程序无法确定的事业务风险“先查询，再建单”本轮到底执行一个还是两个动作在未得到查询结果前写入“应该是 A301 的线缆问题”房间和原因来自事实还是猜测把推测写进工单事实字段“已经帮你提交”是否有真实创建回执员工误以为事情已被受理“继续尝试其他方法”还允许循环几次任务耗时和调用成本失控结构化输出解决的是可解析性，不是自动解决真实性和权限。即使模型返回完全合法的 JSON，也只能代表“它提出了一个候选动作”。权限、阶段、字段来源、工具结果仍由应用程序核验。这个区别要在接口设计时写清，否则把任意 JSON 当
