返回 ResolveAI 项目总览 · 交互图：范围 · 可运行 · SCENARIO
企业 Agent 项目常从一句看似清楚的需求开始：“我们想做一个退款客服 Agent。”真正进入实施后，这句话很快会裂成一组彼此独立的问题：谁拥有退款规则？哪些数据是权威事实？Agent 只能解释政策，还是可以查询订单、发起退款、转交人工？怎样才算业务成功？什么动作绝对不能发生？
如果产品入口是一张 Policy、Workflow、Tool、Knowledge 和 Evaluation 配置大表，客户必须先理解平台内部结构，才能描述自己的业务。另一种常见做法是让模型直接生成全部配置；页面看起来完成得更快，却很难回答这些配置为什么存在、由谁确认、缺失时是否仍能运行。
ResolveAI 的引导式 Scoping 选择了中间路径：客户先提交业务事实，系统用确定性规则生成最小资产计划，人工确认生成或复用方式，平台再创建场景骨架与显式版本绑定。只要必需资产仍是草稿、复用来源不可追溯或运行配置不完整，就绪门禁就保持阻断。
这篇文章只回答一个问题：如何把一句业务需求转换成一个可配置、可检查、可运行并能留下证据的场景，而不把“创建完成”误写成“生产已上线”？
先定义业务问题，而不是先写 Prompt
向导第一步收集的不是模型参数，而是八类业务事实：场景名称、业务范围、业务负责人、权威数据源、客户目标、典型请求、成功定义和明确排除项。
真实产品截图：业务负责人先明确权威数据源、客户目标、成功标准和禁止范围。截图使用脱敏的零售退款场景，不代表真实客户数据。
这些字段不是展示文案。它们进入结构化 BusinessDefinition，并在后续生成场景时分别成为业务 Owner、Source of Truth、运行目标、典型输入和排除边界。这样的设计有两个直接收益。
第一，客户不需要替平台发明 policyVersion 或 Tool Contract ID。第二，后续每个配置建议都可以追溯到一条业务事实，而不是只说“模型认为需要”。
模板在这里仍然有用，但只提供可复用的起点。它不能替客户决定本场景需要哪些资产，也不会把旧场景的整套嵌套配置直接复制成新的业务真相。
用业务问题识别技术能力
第二步仍然不问“要不要 Policy DSL”或“使用哪种编排框架”。页面改为询问六类业务事实：是否需要规则判断、是否必须严格按顺序处理、是否读取业务数据、是否写入业务数据、是否引用知识，以及是否需要人工接管。
真实产品截图：业务人员回答的是判断、顺序、读写、知识和人工协同问题，平台负责把答案映射成技术资产。
当前实现使用确定性映射，而不是让 LLM 自由决定资产结构：
- 需要资格或边界判断时，要求 Policy；
- 需要固定顺序、写操作或人工协同时，要求 Workflow；
- 读取或写入业务数据时，要求 Tool；
- 引用制度、SOP 或产品说明时，要求 Knowledge；
- 写操作或人工接管要求 Human Boundary；
- Evaluation 对所有场景都是必需资产。
这里的“最小”不是资产越少越好，而是只创建能够由业务答案解释的资产。一次只读资格查询可以需要 Policy、Tool 和 Evaluation，却不必为了架构整齐额外创建 Workflow。相反，涉及资金、权益或人工交接的场景会自然带出更多治理对象。
这种确定性推荐牺牲了一部分自由度，换来可复验性：同一组能力答案会生成同一组必需资产，测试可以检查资产是否遗漏，客户也能明确纠正某个答案，而不是和一段长 Prompt 争论。
生成的是资产计划，不是已上线配置
能力访谈结束后，系统创建一个 ScenarioImplementationPlan。计划固定包含 Policy、Workflow、Tool、Knowledge、Human 和 Evaluation 六类建议，每类资产都有 required、处理方式、责任人、理由以及可选的复用来源。
真实产品截图：每种资产分别选择生成草稿、复用已有版本或不需要；必需资产不能被直接移除。
计划中的处理方式只有三种：
generate：创建一个待配置草稿；reuse：引用一个已经存在且当前仍可用的明确版本；not_required：仅适用于非必需能力。
这三个状态解决的是三个不同风险。
生成草稿不能伪装成可运行资产；复用不能只写一个模糊名称，必须绑定资产修订、来源场景和来源配置版本；非必需资产可以不创建，但系统不会允许用户把当前业务答案推导出的必需资产直接删掉。
Archify 技术解释图：业务定义和能力访谈先形成不可变计划与场景绑定，必需资产缺失时返回补齐；门禁通过后才允许产生 Run 证据。图解释当前代码关系，不代表生产部署拓扑。
为什么计划需要独立修订
计划不是页面内的一份临时状态。当前存储把 proposed、confirmed 和 completed 保存为追加式 JSONL 修订。
创建计划得到 revision 1；人工确认资产选择时必须提交期望修订；执行计划前再次检查修订和状态。旧页面、重复请求或并发编辑如果仍持有过期 revision，会收到 revision_conflict，而不是覆盖后来的确认结果。
复用资产还会被检查两次：确认计划时验证一次，真正执行前再次确认该资产修订和来源配置版本仍然可用。这样可以避免用户在页面上选中了一个版本，但执行时系统悄悄换成“最新版本”。
这仍然是单机实践实现，并不等于已经具备跨进程事务和企业审批签名。但它建立了一个重要合同：业务确认和资产创建之间不能靠页面记忆维持一致性。
场景创建完成，为什么仍然可能不能运行
执行确认后的计划会创建场景 ID、配置修订和资产绑定。复用资产保持 ready；新生成资产只会进入 draft。页面会明确告诉用户：场景骨架已经创建，但待配置资产仍需处理。
这一步故意没有把模板中的业务结果直接当作新场景的最终真相。新场景的预期业务状态保持为空，评测负责人、Tool 行为、权限规则和响应模板仍需按当前场景补齐。
就绪检查会集中验证：
- 业务负责人和权威数据源是否存在；
- Policy 版本和作用域是否完整；
- Tool Contract、行为 fixture 和 Guarded Action 是否一致；
- 必需动作是否具有权限规则；
- Expected Outcome、回复模板和评测负责人是否存在；
- 所有资产绑定是否为
ready； - 复用资产是否保留来源场景和配置版本；
- Runtime Profile 是否仍可解析。
只要存在阻断项，结论就是 no_go。如果结构完整，但外部业务适配器仍是 Mock，或者包含写操作和人工接管，结论只能是 conditional_go。它允许本地 Harness 或受控环境继续验证，不代表生产审批已经完成。
真实产品截图：运行页显示固定场景、配置版本、业务真值和模型参数。这里证明本地运行入口及上下文可见，不证明生产业务系统已经接入。
“可运行”的终点不是一段回答，而是一份 Run 证据
场景通过当前环境允许的就绪条件后，运行时会固定场景与配置修订，保存客户输入、结构化 Decision、Policy 和 Guard 结果、Tool 轨迹以及最终 Outcome。
真实产品截图：一次 Run 将输入、回答、结构化候选动作和配置修订分开呈现；业务 Tool 与部分知识行为仍处于明确标注的本地 Harness 边界。
这一步让 Scoping 和后续质量运营真正接上：如果 Run 失败，调查可以回到当时的业务定义、场景版本和资产绑定，而不是只留下“某次对话答错了”。修复也不需要覆盖原场景；它可以创建新资产修订，再用同一业务合同做回归比较。
这套设计真正解决了什么
这条链路没有让模型变得更聪明，它解决的是实施和治理问题。
客户可以用业务语言描述问题；FDE 获得一份可审阅的最小资产计划；平台知道哪些配置是生成草稿、哪些来自明确版本；质量运营可以在运行前看到阻断项，在运行后拿到可追溯证据。
更重要的是，几个容易混淆的状态被分开了：
- 描述完业务问题，不等于已经生成资产；
- 生成资产草稿，不等于资产已就绪；
- 本地 Harness 可以运行，不等于生产 Connector 已验收；
conditional_go不等于生产批准；- 一次 Run 通过，不等于场景已经完成长期评测或客户采用。
当前证据和边界
本文对应的当前工作树已重新运行场景建模聚焦测试：4 个测试文件、24 项测试通过，覆盖最小资产推荐、不可变计划修订、过期写入冲突、场景配置修订、必需资产阻断、复用来源缺失和主要页面交互。
五张产品截图来自既有演示验收素材；本文重新检查了它们的可读性和内容边界，但没有把它们伪装成本次新执行的一条生产端到端链路。Archify 工作流图通过 showcase 结构校验和 1440×900、1600×1000、1920×1080、2048×1320 明暗主题检查。
当前流程在本地运行。进入企业环境还需要接入真实身份与职责分离、生产 Connector、数据库和跨进程事务，并验证客户业务规则、实际副作用、长期容量与任务效果。