2026年7月28日作者：Lei阅读 --

场景控制包：把 Agent 经验从提示词推进到可执行契约

结合 AI Chains、PromptChainer、ReAct、RAG、Self-RAG、DSPy、AutoGen、MetaGPT、Reflexion、Voyager、AgentBench 和 SWE-agent，判断 AIHub 场景控制包有没有同类论文思想：没有找到完整同款，但能看到清晰的相邻研究脉络。

先说结论：我没有找到一篇论文，完整提出了 AIHub 这个“场景控制包”的同款对象。

如果把相似度放宽，能找到很多相邻思想：LLM chain、可视化 prompt workflow、ReAct 式推理-行动循环、RAG 和 Self-RAG、DSPy 的声明式 LM pipeline、多 Agent 协作框架、Reflexion/Voyager 的反馈和技能积累、AgentBench/SWE-agent 的 agent harness 与 interface 设计。

但这些论文大多各管一段：有的管任务分解，有的管工具调用，有的管检索，有的管反馈，有的管评测。AIHub 的场景控制包更像一个平台级工程对象：把业务目标、知识来源、工具绑定、Skill 执行边界、工作流、质量门禁和交付物 YAML 放进同一份可版本化契约里。

所以这篇不硬拗“论文同源”。更准确的判断是：

场景控制包不是某一篇论文的复刻。
它是 Agent 工程从 prompt、chain、RAG、agent framework 继续往前走以后，
自然需要出现的一层：面向业务场景的可执行契约。

这个模块到底在包什么

场景控制包不是“模板换个名字”，也不是“让用户填一份 YAML”。它想解决的是一个更具体的问题：

当一类业务需求会重复发生时，怎样把 Agent 每次都要知道、要查、要做、要验证的东西沉淀成可复用资产？

在 AIHub 的设计里，一个场景控制包至少包含这些层：

层	它回答的问题
业务目标	这个包服务哪类业务场景，完成后世界状态应该变成什么
知识定义	Agent 应该从哪些 GitLab Markdown 或 Feishu 知识源取上下文
配套获取工具	用哪些 MCP 包查询知识、系统或校验结果
执行资产	用哪个 Skill 或 Starter 承载具体业务流程
流程定义	哪些阶段需要显式展示、排序、审计或独立产出
质量门禁	输出之前必须满足哪些检查、引用、覆盖或人工/模型判断标准
交付物预览	最终导出给本地 Codex 或其他 Agent 的可执行 YAML 契约

这几个字段合在一起以后，它就不是一段“教 Agent 怎么做事”的提示词，而是一份可以被平台搜索、安装、运行、审计和迭代的契约。

用一张图看，它的位置大概在这里：

flowchart TD
  A[业务场景] --> B[场景控制包]
  C[知识源<br/>GitLab Markdown / Feishu] --> B
  D[MCP 获取工具] --> B
  E[Skill / Starter] --> B
  F[流程阶段] --> B
  G[质量门禁] --> B
  B --> H[可执行 YAML]
  H --> I[Agent 运行]
  I --> J[运行报告]
  J --> K[知识候选 / 场景改进建议]
  K -. 人审后更新 .-> B

注意最后一段是虚线：知识回写和场景自我改进只能先产生候选建议，不能自动篡改知识库或控制包。这一点很重要。Agent 系统如果没有治理边界，很容易把“越跑越聪明”做成“越跑越不可控”。

论文里最接近的几条线

1. AI Chains / PromptChainer：复杂任务需要可编辑的链

AI Chains 关注的是人和 LLM 协作时，如何把复杂任务拆成多个 LLM 步骤，让用户能查看和修改中间结果。它的核心价值是透明、可控、可调试。后续的 PromptChainer 进一步做成可视化编程界面，支持用户搭 chain、看节点、调试中间输出。

这和场景控制包的“流程画布”很像：复杂任务不要藏在一个大 prompt 里，而要拆成用户能理解的结构。

但它们还不是场景控制包。AI Chains 和 PromptChainer 主要处理 prompt chain authoring：输入输出怎么串、节点怎么调、用户怎么调试。它们没有把企业知识源、MCP 工具、发布资产、权限、质量门禁和可交付运行契约一起纳入同一个包。

场景控制包从这条线继承的不是“可视化画布”本身，而是一个更底层的判断：

复杂 Agent 任务必须有可观察的结构。
不可观察的链路，很难被业务方信任，也很难被工程方复用。

2. ReAct：Agent 不是只生成答案，而是边想边行动

ReAct 把 reasoning trace 和 action 交织起来，让模型一边推理、一边调用外部环境或知识源。它说明了一件今天看来已经很基础、但非常关键的事：Agent 的能力不只来自模型参数，还来自它在执行过程中能否正确行动、观察和修正计划。

场景控制包里的 MCP 和 Skill 边界，与 ReAct 的精神是相通的：不要指望一个 prompt 解决所有事；Agent 需要在任务过程中查知识、调工具、观察结果。

差别也很清楚。ReAct 是一种运行时策略，回答“模型在一步步执行时怎么推理和行动”。场景控制包是运行前的契约，回答“这类任务允许查什么知识、用什么工具、按什么流程、达到什么门禁才算完成”。

如果说 ReAct 是 Agent 的动作循环，场景控制包就是这条动作循环的场景说明书和验收协议。

3. RAG / Self-RAG：知识不能只在模型脑子里

RAG 的问题意识很直接：模型参数里的知识不够可控，知识密集任务需要显式检索外部记忆。论文还明确提到 provenance 和更新知识是开放问题。后来的 Self-RAG 往前走了一步，让模型判断何时检索，并对检索内容和生成结果做自我反思。

这条线和场景控制包里的“知识怎么来”关系很强。场景控制包不把 RAG 当成一个开关，而是把知识拆成可治理字段：

场景控制包字段	对 RAG 问题的工程化回答
`data_sources`	哪些知识源可被使用
`mcp_tools`	通过什么工具取知识
`required_context`	哪些知识项必须覆盖
`missing_context_policy`	缺上下文时是询问、阻塞，还是带警告继续
`quality_gates`	输出是否有引用、覆盖、合规或事实性检查

这比“给 Agent 接一个向量库”更硬。向量库解决的是召回，场景控制包解决的是：谁声明这个知识源、谁能用、用来做什么、缺了怎么办、最后怎么验。

Self-RAG 对应的是模型内的检索与反思机制；场景控制包对应的是平台外的知识契约和门禁机制。一个偏模型/算法，一个偏工程/治理。两者能互补，但不是同一个抽象层。

4. DSPy：从手写 prompt 到声明式 pipeline

DSPy 反对靠试错堆长 prompt template，提出把 LM pipeline 抽象成文本转换图，用声明式模块组合，并围绕 metric 做优化。它和场景控制包相似的点是：都不把 prompt 当核心资产，而是把“可组合、可优化、可评估的程序结构”当核心资产。

但 DSPy 是开发者编程模型。它主要关心如何写 pipeline、如何编译提示、如何用指标优化模块。场景控制包则是平台发布模型：谁拥有这个场景、绑定哪些已发布 Skill/MCP、知识源在哪里、哪些门禁必须满足、最终如何交付给 Agent。

我觉得二者最值得互相借鉴的是“metric”思想。场景控制包现在的质量门禁更像验收规则；未来如果每次运行报告都能沉淀可量化指标，就有机会向 DSPy 的方向靠近：不是自动改 prompt，而是基于运行证据建议改知识项、改门禁、改 workflow 或改 Skill。

5. AutoGen / MetaGPT：工作流和角色不能靠聊天自然涌现

AutoGen 强调多 Agent 可以通过可编程对话模式、工具和人类输入协作完成任务。MetaGPT 更进一步，把人类工作流里的 SOP 编码进多 Agent 协作，减少简单聊天式多 Agent 的级联幻觉和逻辑不一致。

这和场景控制包的“Skill 驱动执行模型”很接近。一个复杂业务流程不一定要在控制包 UI 里拆成十几个显式阶段；如果某个 Skill 已经拥有内部业务步骤，一个粗粒度的“执行主流程”阶段就够了。控制包只需要声明这个阶段绑定哪个 Skill、可用哪些知识和工具、输出受哪些门禁约束。

这其实是对 MetaGPT 式 SOP 思想的工程化拆分：

SOP 的细节放进 Skill。
场景边界、知识、工具和验收放进控制包。
平台负责发现、权限、版本和交付。

这个拆分比把所有流程都塞进一个 YAML 更健康。否则控制包会变成另一个流程黑洞：看似显式，实际和 Skill 内容重复，最后两边一起漂移。

6. Reflexion / Voyager：反馈和技能库很诱人，但必须治理

Reflexion 用语言反馈和 episodic memory 改善 agent 后续决策。Voyager 则把可执行代码技能沉淀成可检索、可组合的 skill library，并用环境反馈和自验证改进程序。

这两篇和场景控制包里的两个延展字段有共鸣：知识飞轮和场景自我改进。一次场景运行之后，Agent 很可能发现知识库缺一条规则、门禁缺一个检查、Skill 内部流程需要补一段异常处理。

但企业平台不能照搬 Voyager 那种开放式自我扩展。Minecraft 世界里学到新技能可以大胆试，真实业务知识库和场景包不能让 Agent 自动改。AIHub 这里把知识回写和场景 RSI 做成 draft/proposal 模式，是一个务实边界：

Agent 可以提出候选改进。
人或有权限的工具负责审查和落库。

这不是保守，而是把反馈学习从“自动变异”改成“受控演进”。

7. AgentBench / SWE-agent：Agent 需要 harness，也需要面向它的接口

AgentBench 把 LLM-as-Agent 放进多个交互环境里评测，强调复杂环境下的长期推理、决策和指令跟随。SWE-agent 则提出 Agent-Computer Interface：Agent 也是一种终端用户，给 Agent 设计好工具接口，会直接影响它完成软件工程任务的能力。

这两条线对场景控制包的启发是：不要只给 Agent 一堆自然语言说明。Agent 需要明确的环境、工具、反馈和验收信号。

场景控制包里的质量门禁和可执行 YAML，其实就是业务任务的轻量 harness：它不只是描述任务，还规定运行时有哪些知识、哪些工具、哪些输出和哪些验收条件。和 AgentBench/SWE-agent 的差别在于，前者偏 benchmark 或软件工程 interface，场景控制包偏企业业务场景的发布与执行契约。

关键差异：论文多是“能力机制”，控制包是“组织契约”

把这些论文放在一起看，会发现一个规律：

研究方向	核心对象	更像场景控制包的哪一部分
AI Chains / PromptChainer	chain / visual workflow	流程画布、可调试中间结构
ReAct	reasoning-action loop	Skill/MCP 执行循环
RAG / Self-RAG	retrieval and critique	知识来源、检索、引用和事实性门禁
DSPy	declarative LM pipeline	声明式结构、metric、可优化 pipeline
AutoGen / MetaGPT	multi-agent workflow / SOP	Skill 驱动流程、多角色协作
Reflexion / Voyager	feedback memory / skill library	知识飞轮、场景改进建议、Skill 复用
AgentBench / SWE-agent	evaluation harness / ACI	可执行环境、工具接口、验收信号

它们都能解释场景控制包的一部分，但没有一篇完整覆盖这些问题：

业务方如何声明一个可复用场景？
知识源如何标准化？
MCP 和 Skill 如何来自发布资产，而不是手填字符串？
缺上下文时如何处理？
质量门禁如何成为一等对象？
场景如何被搜索、分页、权限控制、版本化、交付给本地 Agent？
运行后的知识候选和场景改进建议如何进入人审流程？

这些不是模型论文通常要解决的问题。它们属于 Agent 平台工程和组织流程治理。

所以，如果要给场景控制包一个准确定位，我会这样说：

它不是 prompt engineering。
它不是 RAG pipeline。
它不是 multi-agent framework。
它不是 benchmark harness。

它是一份面向重复业务场景的 Agent operating contract：
把知识、工具、流程、执行资产和验收规则绑定起来，
让下一次同类任务不再从聊天和猜测开始。

为什么这个抽象有价值

Agent 项目做到一定规模以后，真正贵的不是单次回答，而是重复踩这些坑：

每次都要重新解释业务场景。
Agent 不知道该查哪份知识。
知识库有，但没有标准检索入口。
Skill 有，但不知道该在哪个业务边界里用。
工具能调，但不知道缺上下文时该问还是继续。
输出看起来完整，但没有引用、覆盖和验收门禁。
一次任务暴露出知识缺口，下一次仍然重新踩。

场景控制包的价值不是“让 YAML 更漂亮”，而是把这些隐性约定显性化：

把一次次 Agent session 里的经验，升级成下一次可以直接执行的合同。

这也是它和普通 Starter 的区别。Starter 更像“装哪些东西”；场景控制包更像“为了哪类业务目标，怎样使用这些东西，并如何判断结果可交付”。

我认为最重要的设计取舍

第一，不要把控制包做成原始 schema 编辑器。论文里的 PromptChainer/AI Chains 已经说明，复杂链路需要被非专家理解和调试。业务用户需要的是“知识怎么来”“质量门禁”“交付物预览”，不是一堆字段名。

第二，不要把所有流程都摊开到控制包里。MetaGPT 的 SOP 思路有价值，但如果某个 Skill 已经承载了详细业务流程，控制包只需要声明它的执行边界。否则会出现双写和漂移。

第三，RAG 不是一个按钮。RAG 论文解决了知识外置的问题，但企业落地还要解决知识源、权限、引用、缺失上下文和门禁。场景控制包应该把这些都写进契约。

第四，自我改进要先是 proposal，不是自动写回。Reflexion/Voyager 的反馈学习很有启发，但业务系统里更稳的路径是：运行报告产生候选知识和候选场景改进，人审后再更新知识库或控制包。

第五，质量门禁要前置。AgentBench/SWE-agent 都在提醒我们：Agent 的表现高度依赖环境、工具和反馈。不要等输出生成后才想“怎么验”，应该在场景包里先声明验收信号。

一个简单自测

以后判断一个东西是不是“场景控制包”，可以问五个问题：

它是否绑定了明确的业务目标，而不是泛泛的 prompt 模板？
它是否声明了知识源、检索工具和缺上下文策略？
它是否复用已发布的 Skill/MCP 资产，而不是随手写工具名？
它是否有质量门禁，而不是只看模型回答顺不顺眼？
它是否能交付给 Agent 执行，并在运行后产出可审查报告？

如果答案大多是否，那它可能只是 prompt、workflow、RAG 配置或文档模板。它们都有价值，但还不是场景控制包。

最后的判断

我不认为现在能说“场景控制包这个思想已经被某篇论文完整提出过”。能说的是：它站在一组研究趋势的交叉点上。

LLM chain 解决透明和分解；ReAct 解决行动循环；RAG/Self-RAG 解决外部知识和反思；DSPy 解决声明式 pipeline 和 metric；AutoGen/MetaGPT 解决多 Agent workflow 和 SOP；Reflexion/Voyager 解决反馈与技能积累；AgentBench/SWE-agent 解决可执行环境和验收接口。

场景控制包把这些趋势往企业平台方向收束：

把 Agent 能力从“会话里的技巧”，变成“组织里可发布、可安装、可执行、可审计、可迭代的资产”。

这个抽象是否值得继续做，关键不在论文里有没有同名概念，而在它能否稳定减少三件事：重复澄清、错误知识使用、不可验收输出。

如果它能做到，场景控制包就是 Agent 平台里很值得保留的一等对象。