AI 生成的草稿，离能直接交付的成品还差多远？
生成模型什么都能"出"，为什么还是不能"交付"？
十分钟前，你让 AI 写一份二十页的行业报告。它交回来的东西排版漂亮、章节齐全，读着读着你发现第三页的引用是编的，第五章的结论跟第二章打架。你叹口气，把报告发回去让它"再检查一遍"，然后自己花了四个小时改完。
这个场景每天都在无数屏幕上重演。当生成模型把"出草稿"的成本打到接近零，真正卡住实用性的就不再是生成，而是交付。草稿只要看起来对，交付物必须真能用：完整、自洽、可改、坏了能修。你会要求一份能直接讲的 PPT，而不是二十张漂亮的图；你会要求一个能跑起来的程序，而不是一段语法正确的代码。
《Agentic Artifact Creation: Systems, Evaluation, Principles, and Opportunities》这篇综述，把"从草稿到交付"正式立成了一个研究方向。它检索了截至 2026 年 8 月 20 日的 259 篇工作，其中 230 个系统符合它的定义，另有 29 个产物构建基准。定义本身只有一条，却非常锋利：AI 系统实质构造或修订交付物，跨决策保留产物或过程状态，并且至少一次用中间观测重定向后续工作。论文管这叫 stateful construction（有状态的构建）。一句话说就是：生成是一次性的闪光，构建是带着状态一路改下去。AAC
会有读者说：多步循环不是早就有了吗？没错。ReAct 在 2022 年就提出 Thought/Action/Observation 三元组，让模型在推理、行动、观察之间循环，在 ALFWorld 上比模仿学习基线高出 34 个百分点，这是绝对成功率的差距；在 WebShop 上比强化学习基线高出 10 个百分点。ReAct Reflexion 再进一步，把失败反思写成文字存进记忆，下一轮带着记忆重新作答，论文自述在 HumanEval 上做到 91% pass@1，对照当时 GPT-4 的 80%。Reflexion 但循环本身不构成交付保证。循环只是把过程拉长、把环节变多，产物到底能不能用，循环不回答。
所以论文在统计里划了一条软门槛：不是所有"多步生成"都算 agentic artifact creation，只有保留状态、并且中间观测真的改变了后续动作、修订目标或停止决策的才算。这一刀切出了草稿和成品的分界线。配套的 awesome 精选仓库页面上徽章显示 257 篇工作、229 个系统、28 个基准，与摘要差几个，原因是仓库持续收纳新条目、且审计是第一轮粗审，两套数字口径不同，别混用。awesome 仓库
为什么这个问题现在才被认真问出来？三年前，agent 还大多是研究演示，让模型在几个回合里查个资料、算个数就够。今天 agent 已经泡在真实工作流里，草稿的成本归零之后，矛盾全部挤到交付环节。同时"产物"的概念也在扩张：从文本、图像，到 3D 场景、虚拟角色、整个软件仓库。产物越接近"正在被使用的系统"，草稿和成品的差距就越刺眼。这篇综述挑的时机，正好是问题开始变得昂贵的时候。
生成的能力大家都有，剩下的问题是同一个：如果交付不靠生成的瞬间质量，那靠什么？
能"构建"而不是"生成"，系统最少需要哪三块？
论文给了一个极简答案：任何 agentic 构建系统，功能上都由三块咬合成一个闭环。第一块是 operational representation（可操作表示），产物的底盘。代码库、图像画布、文档里的状态，是 agent 能读、能改、能查的那一层。第二块是 construction policy（构建策略），决定下一步做什么。第三块是 runtime verification（运行时验证），检查刚做完的修改，把观测变成反馈，送回策略去修正接下来的动作。
一次生成和这种构建的关系，可以想成照相和施工。按快门是一锤子买卖，照片在按下的瞬间凝固，不满意只能重拍，不能改。施工不一样：工地上始终有半成品状态，工头看现场决定下一步砌哪堵墙，监理检查刚完成的部分，发现问题就让工头返工，直到全部验收合格房子才交付。施工的本质是"改"，而改的前提有三个：状态可读、错误可发现、反馈能回到下一步。这三个前提，正好对应三件套。
论文还特意说明，这三件套是必需件。三件套各自附带的次级维度，比如单 agent 还是多 agent、流程自动还是人工接管、编辑的粒度是整篇还是单行，都是实现选择，不是定义的一部分。判断一个系统是不是 agentic 的，看三件套齐不齐，不看拓扑花不花哨。
论文把闭环写成三个式子：
$$R_{t+1}=U(R_t,a_t),\qquad a_t=\pi(T,R_t,f_t),\qquad f_{t+1}=V(T,R_{t+1},o_{t+1})$$
动作 $a_t$ 通过编辑接口把中间形态 $R_t$ 变成 $R_{t+1}$；策略根据任务、当前状态和反馈选择动作；验证从新的观测里提炼出下一步要用的反馈。三块缺一块，系统就退化成一次性生成。这套闭环在论文里长这样。
图注：论文给出的 agentic artifact creation 功能架构。任务规格进入决策控制，动作经 Edit Interface（编辑接口）修改中间形态，Runtime Verification（运行时验证）把观测变成反馈送回 Construction Policy（构建策略），验收通过才释放交付物。方框内部（navigate、reflect、refine）只是示例实现，不是强制接口。AAC
注意左下角的回路：Runtime Verification 的反馈箭头回到 Construction Policy，构成的是闭环，不是去更新模型的训练信号。
三件套里最容易被误解的是第一块。operational representation（可操作表示）不是记忆。记忆是给 agent 自己读的，可操作表示是产物的实体状态，人和别的 agent 都能对着它操作。Reflexion 的反思日志是记忆，SWE-agent 里的代码库是可操作表示。两者差在"能不能被实际编辑"。
SWE-agent 给可操作表示提供了一个特别具体的工程答案，叫 Agent-Computer Interface（ACI）。它发现直接用通用 shell 的 agent 常被大量无关输出淹没——cat 一类命令会把大半与问题无关的文件内容灌进上下文，grep/find 也会偶尔返回成串无关结果，且 shell 对无效编辑不提供任何反馈。于是为 agent 专门设计了一套接口：File Viewer（看文件）、File Editor（改文件）、Code Search（搜代码），外加上下文管理。这套设计长什么样，论文画了张对比图。
图注：左栏是 LM agent 通过 ACI（File Viewer / File Editor / Code Search）操作计算机，右栏是人通过 VSCode、PyCharm 操作计算机。论文想说的是：agent 也需要一类和 IDE 同等地位的操作接口。图中没有单独画出上下文管理组件。SWE-agent
人通过 IDE 操作代码库效率更高，agent 通过 ACI 操作代码库效率更高，这就是论文的类比，也点出了 operational representation 的工程形态：它是那块"能被 agent 实际编辑和读取"的产物底盘。接口设计对了，效果才来。同一个 GPT-4 Turbo，在 SWE-bench 全量 2294 道真实 GitHub issue 上做到 12.47% pass@1，在 Lite 集上比只给通用 shell 的方式高 10.67 个百分点。SWE-agent
把接口本身当成工程对象认真设计，换来的是同一模型构建表现的显著改写。这是三件套里最反常识的一条，也是它作为一副通用镜片的底气。但镜片是不是真的处处通用？下一章拿它去照六种完全不同的产物。
同样是三件套闭环，为什么文档好验收、3D 场景难验收？
先分清楚都有哪些产物。论文把 230 个系统按产物分成六个家族：文字（textual）、2D 视觉、音频、视频、空间（spatial）、行为（behavioral），一共 16 个分析画像。划分六家族的依据是两件事：哪种失败会让交付物变得不可接受，以及要修复它需要什么样的产物状态。每个家族都有至少五个成熟代表，从写研究报告的 STORM、做音乐的 CoComposer、排 3D 场景的 ShapeCraft，到改代码的 SWE-agent。AAC
横跨六家族，论文提炼出两把决定"构建难度"的尺子。第一把是决策耦合度：这一步的决定跟后面的决定牵扯多深。文档里改一句话，后续段落几乎不受影响；3D 场景里挪一根柱子，光照、碰撞、视角全部要跟着重算。第二把是失败可见性：一个错误要等到哪一步才被发现。两把尺子放在一起，就解释了为什么文档好验收、3D 场景难验收。
失败的发现时机，论文用一张全景图说清楚了。
图注：六产物家族的观测性全景。每个小图按 state、edit、observe 三步语法展开，三列对应三类发现失败的时机：静态检查（文字、2D 视觉）、时间回放（音频、视频）、运行时后果（空间、行为）。论文注明这些是倾向，不是排他模式。AAC
六个家族按"错误在哪一步最容易被发现"排成三档。文字和 2D 视觉靠静态检查，写错当场可见。音频和视频靠回放，得重新播一遍才知道哪里不对。空间和行为靠运行时后果，必须真的跑起来、动起来，错误才暴露。论文特别注明这是倾向而不是排他模式，不是说音频家族就不做静态检查，而是回放是它最自然的观测点。但方向很明确：失败越晚被发现，可修复的窗口越小。软件工程里"越晚发现的 bug 修起来越贵"，在这里是同一个结构。3D 场景里一根柱子放错位置，要等整个场景渲染完才看见，而渲染本身已经烧掉了一大笔算力；文档写错一行字，三秒发现，三秒修好。
两把尺子之外，论文还挂了第三面镜子：可修复性。错误不仅要被发现，还要能被修，而修的前提是状态能定位到坏的那一块。静态检查能指到具体某一行，运行时后果往往只能指到"哪个环节崩了"。文档错一行字，状态就在那一行；3D 场景里一盏灯摆错了位置，连"错在哪一步"都得靠猜。可修复性这根轴，把六个家族的难度差距又拉了一截。
行为类产物还有个别人没有的麻烦：它没有"看"这个动作，只有"跑"。于是"状态放在哪"成了行为家族内部最大的分歧点。Generative Agents 是让 25 个 agent 在虚拟小镇里生活的系统，它把状态放在自然语言记忆流里，用反思和规划更新它。这里的记忆要跟上一章 Reflexion 那类反思日志分清：Reflexion 的记忆是写给模型自己读的，是留给下一个回合的经验小结，真正的产物并不存放在里面；Generative Agents 的记忆流本身就是行为留下的实体状态，agent 的全部感知都写进去，检索把相关记忆读回来，读回来的内容直接决定下一步行动，反思和规划作为更高层的记忆再写回去。同样是"记忆"两个字，一个是模型自读的旁注，一个是可读、可写、并且反过来驱动行为的产物状态。Generative Agents Voyager 走的是另一条路：把状态建造成一座会长大的技能库。库里存的不是回忆，是可执行的 Python 代码。agent 每学会一个新技能，比如造石镐、打僵尸，就把代码写进库，下次直接用，检索时按相关度调出前几个。这套结构长这样。
图注：Voyager 的三组件闭环。左侧自动课程持续提出下一个要探索的任务，中部技能库用向量数据库存可执行代码，右侧迭代式提示把环境反馈、执行错误与自我验证三路信号送回代码生成循环。Voyager
在 Minecraft 里，Voyager 靠这三个组件能发现基线方法 3.3 倍的物品种类。Voyager 记忆派和技能派的差别是本质的：一段语言摘要不能直接当动作执行，一段可执行代码可以。但这不意味着上一章那条边界松动了。operational representation（可操作表示）依然是产物状态，不是给模型自读的记忆：Reflexion 的反思日志不承担产物状态，所以只是记忆；Generative Agents 的记忆流可被读取、可被更新，读出来的内容直接驱动后续行为，它已经充当了行为产物的实体状态，因此在行为家族里稳稳站住了可操作表示的位置。判别标准始终是那一句：这段状态能不能被实际操作，而不是它叫不叫记忆。
六家族各自有各自的"最难一步"，根源不在模态，在两把尺子上。承认差异之后，更锋利的问题来了：有没有所有家族都绕不开的共性坑？有，而且每一个都不在生成质量上。下一章看三个最直觉的解法是怎么先后翻车的。
拆开做、让模型自查、出了错重来——三个直觉解法为什么都不够？
遇到难构建的产物，工程师的条件反射通常是三个直觉解法：把任务拆给多个 agent；让模型自己审查自己的产出；错了就重来一遍。这篇论文逐个拆台：三个都靠不住，而且失败不在调参，在结构。
先看"拆开做"。拆解确实降低了每个子任务的局部复杂度，但协调和重组的成本长了出来。谁维护全局承诺？冲突谁来裁决？状态跨过分工边界后还活不活着？论文的表述是：关键不在于系统调用了多少次模型，而在于谁维护全局承诺、冲突如何裁决、状态能否跨边界存活。AAC 工程样本能让人感受一下成本量级：MetaGPT 让五个角色按标准作业流程做软件，平均消耗 24,613 个 token；MetaGPT ChatDev 用对话链，平均 19,292 个 token。ChatDev 折算到每行代码，分别是 126.5 token/行和 248.9 token/行。不过这两组数字来自不同的系统和流程，论文没有把它们设计成可控对照，只能当作成本量级的参考样本，不能据此直接归因拆解方式的优劣。
再看"让模型自己当裁判"。这是三个解法里最反直觉的一个：它不仅没用，还有害。Self-Correct 做了个干净利落的实验：让 GPT-3.5、GPT-4、GPT-4-Turbo、Llama-2 四个模型，在 GSM8K、CommonSenseQA、HotpotQA 三个推理基准上先答一遍，再自己检查、自己改，全程没有外部反馈。在这个无外部反馈的设定下，结果是一致的：所有模型在所有基准上准确率全部下降。Self-Correct 锚论文给出的结构性解释是：同一个模型判断自己推理的对错，用的正是生成答案时的那套偏好和盲区，生成器错在哪，裁判就瞎在哪。需要说明的是，偏好与盲区共享目前是锚论文提出的结构性风险解释；退化结果本身直接证明的是无外部反馈的自改会越改越差，要坐实这一机制，还需要专门的实验去分离验证。这种由模型自己充当裁判的做法有个名字，learned judge（学习型裁判）。这里要分清一个概念：learned judge 不是 RLHF 里那种专门训练出来的 reward model。奖励模型是独立训练的裁判，learned judge 是拿生成器本身或者同源模型顶上去的裁判，独立性从一开始就先天不足。Reflexion 的自我反思本质上也是同源判断的结构风险，论文自己承认在 WebShop 上陷入了局部最小值。Reflexion
这套机制可以画成一张两岔图。
左路是直觉做法：草稿交给同一个模型自评，按论文的解释，判断与生成同源，偏好和盲区共享，缺陷不可见，反馈无效，越改越差，Self-Correct 的实测正是在这条路上给出全面退化的证据。右路是论文主张的方向：验证必须来自生成器之外的独立证据源。
"出了错重来"也一样，问题不在"重来"，在重来的方向。不知道错在哪的重来，只是用同一副盲区再赌一把。论文的主张是：真正有效的反馈必须来自生成器之外，而且指向具体位置。AgentCoder 是这个方向最干净的工程案例：三个固定角色，Programmer 出代码，Test Designer 出测试用例，而且测试设计者看不到代码，从源头避免测试被已写下的代码带偏；Test Executor 在本地真实执行，把具体的错误信息喂回给 Programmer 定向修改。
图注：AgentCoder 的三角色闭环。Programmer（蓝）出代码，Test Designer（绿）出测试用例且看不到代码，Test Executor（橙）在本地执行；通过就返回可用代码，失败则把错误反馈回流给前两者。图中示例是 has_close_elements 这道编程题。AgentCoder
测试独立于生成，执行独立于模型，这正是它在结构上增加独立证据的地方：测试设计被隔离在代码之外，执行落在真实环境里。论文报告这套配置在 HumanEval 上做到 96.3% pass@1，基于 GPT-4，数字出自 arXiv v3 报告。AgentCoder 但要守住尺度：这是单一 benchmark 在单一模型上的成绩，说明这条路径走得通，还不能当作独立验证具备一般因果效力的证据。两边的证据方向正好相反：Self-Correct 在无外部反馈设定下测出了 learned judge 的退化，AgentCoder 提供了独立证据这一侧的结构样本。表面功夫差不多，一个结构把裁判和运动员绑在一起，另一个结构把两者拆开。
三个直觉解法的教训可以收成三条：验证必须独立于生成；反馈必须指向具体修改；状态必须能跨边界存活。下一章，论文把这三条连同其他教训磨成一张检查清单。
面对一个 AI 构建系统，论文给你的检查清单是什么？
把前面的拆解收起来，论文给了一张能带走的检查清单：四条原则。它们全部围绕同一个中心展开，那就是可寻址的产物状态（addressable artifact state），也就是那个"改了能查、查了能改"的状态。
图注：论文的四条原则围绕中心的可寻址产物状态形成四向连接：承诺接到状态、后果接到责任、证据接到修复、变更接到重验证。论文强调这是定性透镜，不是顺序流程，也不是成熟度阶梯。AAC
四条原则和它们的工程例子可以排成一张小表。
| 原则 | 一句话含义 | 工程例子 |
|---|---|---|
| Externalize Commitments（外显承诺） | 把隐性的验收标准落到可寻址状态上 | SWE-agent 的 ACI 显式接口 |
| Define Control Boundaries（划定控制边界） | 把依赖和后果接到决策责任上 | 每个 agent 的决策责任边界 |
| Make Feedback Actionable（反馈转定向修复） | 把证据接到有界的修复动作上 | AgentCoder 的独立测试反馈 |
| Revalidate Affected State（变更后选择性重验证） | 改了哪里就重验哪里 | 软件工程里的增量测试 |
第一条是 SWE-agent 的主场：文件能看、能改、能搜，全是显式接口，模型和人对着同一份状态说话，凭感觉承诺的空间被压到最小。第三条是 AgentCoder 的主场：错误信息指向具体代码段，等于把"不行"翻译成"哪里不行、怎么改"。第四条最日常：改哪段就重测哪段，而不是每次变更把整个项目从头跑一遍。
论文特意强调，这四条是定性透镜，不是顺序流水线，也不是成熟度阶梯，没有"先做哪条再做哪条"的讲究，四条是可以单独审视的检查点。还有个细节提醒：摘要里这四条被压缩成了三条，也就是承诺与责任显式化、反馈转定向修复、变更后重验证受影响状态，正文才拆成四条，读论文时别被两个版本弄混。AAC
检查清单之外，论文还纠正了一个分类习惯：评估一个系统时，产物家族只是一条坐标轴。同一个系统既属于六个家族之一，也属于六个应用域之一（创意生产、品牌传播、教育支持、专业工作、科学研究、工程设计），评测实践则是第三条独立的轴。论文把评测单列成独立维度是有道理的：统计里的 29 个基准，测的是构建过程本身，而不是生成质量。配套的 awesome 仓库统计里，220 篇工作（85.6%）同时带了产物与应用双标签，Behavioral 类产物占 28.8%，Creative Production 类应用占 33.9%，229 个系统里 95.2% 有可核验的名字。awesome 仓库
检查清单可以翻译成你自己项目的取舍语言：把隐性承诺写成显式状态；把失败信号接到具体修改而不是整体重来；每次变更只重验证受影响的部分。但这套东西看起来完备，它自己在哪些地方还撑不住？论文把短板亲手交了出来。
这套框架现在卡在哪，下一步该谁来做？
论文的诚实之处在于，它把六个开放挑战当作自己的局限摆出来。这不是客套，这六个挑战就是六扇机会门，每一扇门背后都对应一个目前还没人做成的事。
| 开放挑战 | 卡在哪 |
|---|---|
| Global Coherence under Decision Interdependence | 决策耦合太深时，怎么保证全局协调一致 |
| Targeted Repair under Self-Diagnosis Limits | learned judge 不独立，谁来告诉系统错在哪 |
| System Self-Evolution beyond Task-Specific Gains | 超越单个任务的自我进化，技能库只是雏形 |
| Personalization under Evolving Creator Intent | 创作者边看成品边改主意，系统怎么跟上 |
| Human Authority under Agentic Delegation | agent 干得越多，人还剩多少控制权 |
| Reliable Evaluation of Open-Ended Artifacts | 没有标准答案的产物怎么打分 |
六个挑战可以粗分成两侧：前三个在系统侧，怎么保持全局协调、怎么定位错误、怎么自我进化；后三个在人机侧，意图怎么跟上创作者、权威怎么留在人手里、开放产物怎么被公平评价。系统侧是工程问题，人机侧是接口和治理问题，两边都还没见到像样的解法。
其中最值得盯着的是第三条，系统自我进化。Voyager 的技能库已经展示了雏形：一座会长大的可执行代码库，每学会一个新技能就写进去，下次直接调用。这已经是一个不断增长的 operational representation，但从"库里存技能"到"系统自己决定学什么、为什么学"，中间还有很长的路。Voyager
读这篇综述也需要一点批判性，论文自己交代了三条边界。第一，定义要求系统实质构造或修订交付物、并用中间观测重定向后续工作，这会把纯检索、纯评测类的系统挡在门外。第二，六个开放挑战兼任了局限的角色，但它不是一份完整的局限综述。第三，数字口径要留意：论文摘要写 259 篇工作，配套仓库徽章写 257，差异来自仓库的持续更新和第一轮审计，两套数字别混着用。另外还要记住，这是 2026 年 8 月 28 日提交的 arXiv preprint（cs.MM），v1 是唯一公开版本，没有会议或期刊背书，数字和论断都可能被后续版本修订。
把三件套、两把尺子、四条原则装进兜里，下次再拿到任何一个 AI 构建系统，都可以先问三个问题：它的产物是可寻址的状态吗？它的反馈来自生成器之外吗？它改了哪里就重验哪里？生成模型把出草稿的成本打到接近零的那一天，谁把改的成本也打下来，谁就拿到了下一轮的钥匙。生成是闪光时刻，交付是纪律问题。
想深入可以读原文：Agentic Artifact Creation: Systems, Evaluation, Principles, and Opportunities — arXiv:2608.28122
参考文献
- Agentic Artifact Creation: Systems, Evaluation, Principles, and Opportunities（锚论文），https://arxiv.org/abs/2608.28122
- ReAct: Synergizing Reasoning and Acting in Language Models，https://arxiv.org/abs/2210.03629
- Reflexion: Language Agents with Verbal Reinforcement Learning，https://arxiv.org/abs/2303.11366
- Generative Agents: Interactive Simulacra of Human Behavior，https://arxiv.org/abs/2304.03442
- MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework，https://arxiv.org/abs/2308.00352
- ChatDev: Communicative Agents for Software Development，https://arxiv.org/abs/2307.07924
- AgentCoder: Multi-Agent-Based Code Generation with Iterative Testing and Optimisation，https://arxiv.org/abs/2312.13010
- SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering，https://arxiv.org/abs/2405.15793
- Voyager: An Open-Ended Embodied Agent with Large Language Models，https://arxiv.org/abs/2305.16291
- Large Language Models Cannot Self-Correct Reasoning Yet，https://arxiv.org/abs/2310.01798
- awesome-agentic-artifact-creation（论文配套精选清单），https://github.com/GeminiLight/awesome-agentic-artifact-creation