多 Agent 结果治理：任务委派、产物契约与 Reviewer 返工闭环

上一小节，咱们让总导演把剧情设计任务交给了 Subagent。Subagent 读取世界观和 Skill，完成设计，再把结果保存到 Workspace。

文件有了，就可以直接交给用户了吗？

大家还记得咱们的世界观吗？

咱们的世界观设计的是：太空站已经失联，无法恢复对外通信，也无法获得外部救援。

那么，假设某个结局却写成了这样：

林澜恢复了对外通信，成功联系地球，救援飞船赶到并接走了所有人。

看着挺符合大欢乐结局的，但是，这样的结局却是违背了世界观的。

所以，多 Agent 把任务分出去以后，咱们还得继续处理：**结果有没有问题？问题在哪个文件？交给谁修改？ ** 等等的问题

这一节，咱们就用这个所谓的 “错误结局”，完成一次“检查、局部返工、重新验收”的完整过程。

任务和交付

假设现在让你修改这个结局，只说一句“结局不太好，重新写一下”，你大概率也不知道该怎么改。

所以，给 Subagent 委派任务时，同样需要把这些事情说清楚（调用 AI 的基本素养了）。

这个提示词咱们可以按照下面的方式进行设计：

要做什么：修复休眠结局中违反世界规则的内容。
依据什么：读取世界观、现有场景和审核报告，按照 Skill 中的方法修改。
改到哪里：只修改 ending-b.json，其他场景保持不变。
怎样算完成：去掉外部救援，保留休眠的收益和代价，不改变场景 ID 和分支关系。

有了这些信息，编写者才能围绕一个明确的目标工作。后面的代码会把它们整理成一份任务单，再通过上一节使用过的 task 工具交给 Subagent。

任务说清楚以后，还要约定：最终交回来的文件应该长什么样。

上一节的大纲用 Markdown 保存，方便阅读。

接下来要做可以点击选项的剧情游戏，页面就需要明确知道：当前场景叫什么、显示哪些文字、每个选项跳到哪里。

所以，本例会把场景保存为 JSON。刚才那个有问题的结局，完整内容是：

{
	"id": "ending-b",
	"title": "远方的回应",
	"content": "林澜启动休眠舱，大家降低消耗并暂停维修。随后林澜恢复了对外通信，成功联系地球，救援飞船赶到并接走了所有人。",
	"ending": true,
	"choices": []
}

其中，id 用来识别场景，title 和 content 是要展示的内容。

ending: true 表示这是结局，choices: [] 表示到这里结束，不再提供后续选项。

咱们把这种“文件放在哪里、包含什么字段、需要满足哪些规则”的交付约定，叫作 产物契约。这里的产物，就是 Agent 保存下来的场景、报告等文件。

这是本项目对交付要求的概括。落实到代码中，会用 JSON Schema 描述文件结构，再由普通代码检查字段和业务规则。

先约定交什么，再检查有没有交对，多 Agent 的结果才能继续被程序使用。

场景文件两层验收

前面，咱们已经约定了场景文件应该包含哪些字段。Subagent 把文件交回来以后，接下来就要确认：这份结果能不能继续用于制作游戏。

这里需要检查两件事：文件结构和场景连接是否正确，以及故事内容是否符合世界观。

咱们分别来看。

第一层：用程序检查文件结构和场景连接

先按照刚才的交付要求，检查 ending-b.json：

{
	"id": "ending-b",
	"title": "远方的回应",
	"content": "林澜启动休眠舱，大家降低消耗并暂停维修。随后林澜恢复了对外通信，成功联系地球，救援飞船赶到并接走了所有人。",
	"ending": true,
	"choices": []
}

检查什么呢？看下面这三条哈

检查什么	文件里的实际内容	结果
场景 ID、标题和正文是否是非空字符串	id、title、content 都有对应文字	通过
结局标记是否是布尔值	ending 的值是 true	通过
结局是否已经停止提供选项	choices 是空数组	通过

这些判断都可以交给普通代码执行。比如缺少 content，或者把 ending 写成字符串，程序就会指出文件不符合约定。

接下来，还要检查文件之间能不能连起来。

本例除了 ending-b.json