← 跨层研究

从沙盒走向 IWE

沙盒把 Agent 隔离起来不造成破坏。IWE 把 Agent 武装起来做对的事。前者是防守，后者是进攻。

从沙盒走向 IWE

跨层连接器。 上游概念：知识层 (knowledge/) 的框架/策略/事实/设计，运行时层 (architecture/) 的 Hooks/Flag 控制切面。下游作用于：演化层 — Jargon RL 的模型学习阶段训练数据来源。IWE 是知识资产从静态定义变为 Agent 可消费工作环境的部署格式。

沙盒已经不够了

给 Agent 一个沙盒——无网络、隔离的文件系统、一个 Shell——是当前 Agent 工程的基线。Claude Code、Codex、Devin 都在这个基线上工作。沙盒解决了一个真实的问题：Agent 不能碰外面的东西。安全、可控、可重置。

但沙盒只回答了"Agent 不能做什么"。它没有回答"Agent 应该做什么"。

把 Agent 放进一个空沙盒，给它一个任务——比如"审核这 100 份 ICT 项目可研报告"——Agent 面对的是空白。它不知道：

  • 这个领域有哪些维度需要关注（客户是谁？项目类型是科创还是普通投资？预算是多少？）
  • 什么算合格（这份材料能不能过？那个项目和去年的重复了吗？ITSM 工单被伪装成研发需求了吗？）
  • 原材料长什么样（厂家给的 .docx 怎么读？调研表格的数据怎么提取？）
  • 产出物应该是什么格式（审核简报是 Markdown 还是 docx？表格是几列的？）

Agent 可以在沙盒里写代码来解决这些问题——从零开始。于是它开始：写个 Pydantic 模型定义字段、写几个校验函数、写个 Jinja2 模板、写个脚本把数据灌进去。这份代码可能写得不错，也可能漏掉关键规则。更重要的是——下一个 Agent、下一个任务、下一次运行，这些代码要重写一遍。

沙盒给了 Agent 自由，但没有给 Agent 知识。自由在第一次运行时是资产，在第一百次运行时是负债。

什么值得装进沙盒

不是所有工作都适合被预置框架和策略约束。有些工作需要自由。

排除研发、产品、设计、战略、销售、博弈、创新之后，剩下的那类工作，是运营。运营的特征是四个"确定"：环境稳定、标准固定、方法已知、信息完备。

  • ICT 项目每年 5-8 月集中申报——环境稳定。
  • ITSM 工单不能当做研发项目申报——标准固定。
  • 厂家材料 → 内部审核 → 可研撰写 → 校审 → 提交——方法已知。
  • 项目名称、预算、材料清单都有明确载体——信息完备。

研发不适合装进 IWE——方案没定，需求在变，昨天的策略今天就成了技术债。创作也不适合——没有固定标准，"好不好"由审美判断而非可枚举的规则决定。战略决策更是如此——信息不完备、后果不可逆、无法模板化。

OPS 的价值不在于告诉你怎么做运营，而在于告诉你哪些工作值得做运营。如果一个任务的环境不稳定、标准不固定、方法不已知、信息不完备——那就不要试图把它装进 IWE。先去把环境搞稳定、把标准搞固定、把方法摸清楚。四个条件都满足了，再回来。

IWE 是运营工作的引擎。不是所有工作都是运营。

从空白到预置

IWE 的思路是反过来的：Agent 不需要自由——Agent 需要一个被精确定义的工作台。

沙盒                          IWE
┌──────────┐                  ┌──────────────────┐
│          │                  │  框架（看什么）     │
│  Agent   │                  │  策略（DoD）       │
│  + Shell │                  │  模板（产出格式）   │
│  + 自由  │                  │  样式（视觉规范）   │
│          │                  │  工具（校验脚本）   │
│  (空白)  │                  │  材料（原始文档）   │
│          │                  │                   │
│          │                  │  Agent            │
│          │                  │  + Shell          │
│          │                  │  - 自由            │
└──────────┘                  └──────────────────┘

IWE 是沙盒的领域化。它不是"比沙盒更安全"，而是"比沙盒更有知识"。沙盒回答"Agent 不能碰什么"，IWE 回答"Agent 应该知道什么"。

这个"应该知道什么"不是一股脑塞进 system prompt 的知识片段——它被结构化为四个可独立运作的组件：

1. 框架 —— Agent 的坐标系

框架告诉 Agent 这个领域有哪些维度，但不定义对错。

class Project(BaseModel):
    name: str
    client: str
    year: int
    type: ProjectType          # 科创 / 普通投资
    stage: ReviewStage          # 厂家提交 → ... → 已通过
    submissions: list[DocumentSubmission]

Agent 拿到一份材料，知道要从中提取这些字段、理解这些分类、关注这些维度。框架不教 Agent 怎么判断——它只告诉 Agent"你看这些东西"。

2. 策略 —— Agent 的 DoD

策略定义了"什么算合格"。四层，从快到慢：

| 层 | 反馈速度 | 谁判定 | 例子 | |----|---------|--------|------| | Validator | 毫秒 | Pydantic | vCPU 不能超过 10000 | | Assertion | 秒 | Pytest | 同年同客户不能有同名项目 | | Rubric | 分钟 | Agent 自评 | 材料完整性 30 分，一致性 25 分…… | | HITL | 小时 | 人 | 投资 > 500 万必须人工审核 |

Agent 在 IWE 里不是"做完再检查"——它是边做边检查。修改一个字段，跑一遍 validator。修改完一批，跑 assertion。全部通过后，自评 rubric。如果 rubric 得分 85+，自动放行。如果 60-80，标记人工复核。

策略不是终点关卡。策略是 Agent 的即时反馈回路。

3. 模板与样式 —— Agent 的产出格式

Agent 不需要决定"审核简报应该长什么样"。模板已经定义了信息架构：先展示什么、后展示什么、表格几列、章节怎么排。样式定义了视觉规范：中文字体、字号、颜色、间距。

Agent 的工作不是"设计一份报告"，而是把校验过的事实填入模板。内容正确 + 模板正确 = 产物正确。

4. 材料 —— Agent 要处理的东西

材料有两种形态：

  • 已提取的结构化事实：projects.json、surveys.json——Agent 可以直接使用
  • 原始文档：厂家提供的 .docx——Agent 需要先做内容提取

IWE 不假设材料是干净的。它包含内容提取工具（AtomDoc 的 split、Typedown 的 entity 提取），让 Agent 在沙盒内完成从"脏材料"到"结构化事实"的转换。提取结果的正确性由策略层校验——提取出的字段不全？Validator 报错。提取出两个同名项目？Assertion 报重复。

为什么不是"更好的 prompt"

一个自然的反驳是：这些知识写进 system prompt 不就行了？

不行。原因不是 prompt 不够长，而是 prompt 无法被独立测试、版本化和跨 Agent 复用。

  • 独立测试：一句 prompt 里的"同年同客户不能有同名项目"——你怎么验证 Agent 真的执行了这条规则？在 IWE 里，这条规则是一个 assert_no_same_year_duplicate() 函数，有输入、有输出、有 pytest 测试用例。
  • 版本化：框架改了（加了新字段"是否续期项目"），策略改了（续期项目允许跨年重复），事实改了（客户清单更新了）——三件事在 prompt 里是混在一起的。在 IWE 里分属三个目录，各自有各自的变更轨道。
  • 跨 Agent 复用：一个 IWE 可以被不同的 Agent 实例使用。Claude Code 的 Agent 可以跑，未来的其他 Agent 也可以跑。策略和框架不绑定到特定的 Agent 实现。

IWE 作为 RL 环境

静态 IWE 的另一个属性是：它是可重置的确定性环境。

State:  注入的材料快照 + Agent 的当前产出
Action: Agent 修改产出、重新分类项目、补充缺失字段
Reward: Validator +1, Assertion +5, Rubric 0-100, HITL +50
Episode: 全部绿灯 / Agent 标记需要 HITL / 超过最大迭代次数

Agent 在 IWE 里的每一次迭代——被 validator 拦截了一个字段、被 assertion 发现了一个重复、被 rubric 扣了 15 分——都自动产生一个 (rejected_output, chosen_output) 对。不是人工标注，是 IWE 运行的副产品。

一个 5-8 月的申报季，100+ 份材料，Agent 在 IWE 里迭代成千上万次——产出的不仅是校验过的可研报告，还有几千个高质量偏好对。这些偏好对直接可用于 DPO 训练，训练的对象可以是下一个版本的 Agent，也可以是同一个 Agent 在有新规则的新 IWE 里。

从沙盒到 IWE 的路径

这不是一个必须一次完成的迁移。从空沙盒到完整 IWE，可以渐进式构建：

  1. 只有沙盒：Agent 从零写校验代码。每次任务重写一遍。
  2. 有了框架：Pydantic 模型写好了，Agent 知道要提取哪些字段。但校验逻辑还是每次重写。
  3. 有了策略：Validator + Assertion 写好了，Agent 跑校验获得即时反馈。但材料还是脏的，需要 Agent 自己处理。
  4. 有了模板：产出格式固定了，Agent 不再设计报告结构，只管填入校验过的事实。
  5. 有了内容提取工具：AtomDoc 处理 docx，Typedown 处理结构化实体提取。材料从"脏"到"干净"的转换也有了校验。
  6. 完整的 IWE：框架 + 策略 + 模板 + 样式 + 内容提取工具 + 样本材料。Agent 进去就能开始工作，不需要"先理解再行动"——框架已经定义了理解的方式，策略已经定义了行动的标准。

每一步都独立产生价值。你不必等到第六步才获得好处——第一步加上 Pydantic 模型，Agent 的提取质量就已经比空白沙盒高出很多。

IWE 是 Agent 的接口

最终，IWE 回答了一个比"怎么让 Agent 做对"更根本的问题：人和 Agent、Agent 和 Agent 之间，怎么共享对一项工作的理解？

在软件工程里，API 契约定义了"你调用这个接口，你得到这个结果"。在运营工程里，IWE 定义了"你进入这个工作环境，你遵循这些标准，你产出这些交付物"。

沙盒把 Agent 隔离起来，让它不造成破坏。IWE 把 Agent 武装起来，让它做对的事。前者是防守，后者是进攻。