Chunlin 的论文科普

为什么AI做简单任务很厉害，做复杂交付物就不行？

LLM 与智能体

你可能见过AI一秒生成海报、写代码、做视频，但真要它交出一份「能用的成品」——比如版面合理、内容没漏的学术海报，能跑通测试的完整功能，逻辑自洽的长文档——它往往要么丢三落四，要么前后矛盾。问题到底出在哪？AI要从「生成碎片内容」走到「交付可靠成品」，需要跨越哪些关键门槛？

从「拍立得」到「AI工匠」：交付物不是一次生成的

以前我们用AI生成内容，体验很像拍立得：输入一句提示，按一下快门，几秒出一张图或一段文字。不满意怎么办？要么改提示重拍，要么自己拿修图软件慢慢改。整个过程是一次性的——AI只负责生成，不负责修改，也记不住上一次生成了什么。

但要交付一个真正能用的复杂成品，这种模式就不够了。你做一张学术海报，不可能一次生成就完美：标题可能太长，图表可能放错位置，参考文献可能漏了一半。你需要反复调整，改这一块的时候不能破坏另一块，还得记住之前定下来的整体风格和结构。

这就是最近被系统讨论的智能体式人工制品创建（Agentic Artifact Creation）——AI不再是按一下就出片的相机，更像一个带着草图本的工匠：它有明确的当前进度，能检查自己做到哪一步了，发现问题就针对性修复，而不是每次都推倒重来 [1]。

当然，实际情况比这个比喻更复杂：工匠的草图本、施工计划和质检流程，在AI系统里都是需要精心设计的模块。

做一张合格的海报，为什么比想象中难？

你可能觉得做海报不算什么复杂任务——AI连画油画都行，做个海报还不容易？但如果我们把「合格」的标准列出来，事情就没那么简单了。

一篇关于智能体式创建的综述里举了科学海报的例子：一张合格的学术海报，至少要同时满足三类约束 [1]：

这三类约束的检查方式完全不一样：内容对不对要和原文比对，版面合不合理要算坐标和尺寸，传达效果则涉及人的认知习惯。你没法用一句「生成一张好看的学术海报」让AI一次性搞定——约束越多，不同约束之间越容易打架，直接生成的结果就越不可靠。

软件也是一样。你让AI写一个完整功能，它可能代码写得很漂亮，但一跑测试就报错；修了这个bug，又引入新的bug。因为软件的验收标准是可执行的——每一个测试用例都是一个约束，而约束之间的相互作用，往往不是一次性生成能覆盖的 [1]。

「边做边查」的AI工匠：三个核心角色怎么配合

那一个能交付成品的AI系统，到底长什么样？综述把它拆解成三个循环协作的角色，你可以理解成「设计师-草图本-质检员」的组合 [1]：

第一个角色叫操作表示（Operational Representation），也就是「草图本」。它承载着制品的当前状态，还暴露了编辑接口——不是每次重画整张，而是可以改某一个元素、调整某一段关系、甚至做整体重排。比如做海报时，它不是存一张图片，而是存标题、正文块、图片、各自的位置和样式，你可以单独移动标题而不碰图表 [1]。

第二个角色叫构建策略（Construction Policy），也就是「设计师」。它决定下一步做什么：是先搭大纲，还是先填内容；发现问题时，是局部修复还是整体调整。它可以是预设好的工作流，也可以是AI自主决策；可以是单个智能体，也可以是多个分工协作的智能体 [1]。

第三个角色叫运行时验证（Runtime Verification），也就是「质检员」。它负责检查每一步改动的后果，然后把反馈告诉设计师。反馈有深浅：最浅的是告诉你「通过/没通过」，深一点的能告诉你「哪里出了问题」，最深的甚至能告诉你「应该怎么修」。检查的来源也很多：可以直接看制品状态，可以跑测试看行为，可以用AI评分，也可以等真人用户反馈 [1]。

这三个角色凑在一起，才形成「做一步、查一步、改一步」的闭环。缺了任何一个，要么回到一次性生成的老路，要么变成瞎改一气。

分解是把双刃剑：拆得越碎，拼回去越难

面对复杂任务，一个很自然的想法是：把大任务拆成小任务，每个小任务交给专门的AI去做，最后拼起来不就行了？

道理是这个道理，但实际操作中，分解是一把双刃剑。综述明确指出：分解确实能降低局部复杂度，但会增加协调和重组的成本 [1]。

你可以想象装修房子：水电、木工、瓦工、油工，每个工种单干都没问题，各干各的也很快。但最后拼到一起，可能插座被家具挡住了，水管和电线打架了，吊顶高度和空调尺寸对不上——拆得越细，协调的工作量越大，出问题的地方反而越多。

多智能体系统也是一样。一个叫 Meta-Agent 的框架就专门针对这个问题做了设计：它不是简单把任务拆给多个智能体就完事了，而是在构建阶段就给每个子任务定义明确的输入输出契约和验证标准，执行阶段还有专门的协调者来管中间产物的交接，甚至有三级错误归因机制来区分是本地错了、上游错了还是结构本身就错了 [8]。

这也解释了为什么很多时候，简单拆成多个智能体反而不如单个智能体做得好——拆分本身不是解药，拆分后的协调和验证才是真正的难点。

不是越复杂越好：轻量智能体的反直觉优势

说到这里，你可能会觉得：既然要协调、要验证、要状态跟踪，那系统肯定越复杂越强吧？

还真不一定。有一篇论文专门对比了两个完整的智能体系统：功能更全、架构更复杂的 OpenClaw，和更轻量的 NanoBot。结果有点反直觉：在主基准测试里，OpenClaw 的全任务完成率是 31%，NanoBot 是 25%，差了 6 个百分点，但统计上并不显著——换句话说，你没法说复杂的那个就真的更强 [2]。

更有意思的是资源消耗：在详细测量层，OpenClaw 的耗时是 NanoBot 的约 3 倍，峰值内存更是接近 20 倍 [2]。也就是说，哪怕成功率差不多，复杂系统的运营成本可能高一个数量级。

论文里还提出了一个很实在的概念叫「弱支配」：如果一个系统结果不差、但资源更少，那它就是弱支配的。在 23 条详细测试里，NanoBot 有 18 条都弱支配 OpenClaw——其中 10 条是「两个系统都失败了，但 NanoBot 用更少的时间和内存就失败了」 [2]。

这提醒我们：评估智能体不能只看成功率，失败的成本同样重要。毕竟在真实场景里，大部分任务可能都是失败的，那失败得便宜点、快点，也是一种优势。

复杂任务下，「记忆」和「状态跟踪」有多重要？

那什么才是真正影响复杂任务表现的关键因素？一个移动助手基准测试给出了很直观的答案：记忆和状态跟踪。

这个叫 GMA 的基准把任务分成四级难度，从单步操作到跨四五个应用的真实场景。结果发现，AI 做简单任务几乎人人满分，但一到最复杂的真实任务，最强的模型成功率也不到 20% [3]。

那怎么提升复杂任务的表现？他们做了一系列消融实验，其中两个发现特别有启发性 [3]：

第一个是上下文保留的方式很重要。如果你只是把之前的截图一张张堆给AI，加到8张还有提升，加到16张就没用了。但如果你把看过的旧页面用文字总结记下来，在最复杂的真实任务上，完成率直接从 11% 涨到了近 35%——就像人做复杂事时记笔记，光靠脑子记画面不够，写下来才管用 [3]。

第二个是显式状态跟踪效果显著。给AI加一个「任务进度条」，不管截图多还是少，都能明显提升复杂任务的完成率。比如只有1张截图时，显式状态跟踪把真实任务的平均完成率从 9.97% 提到了 25.89%；就算有16张截图，也能从 23.81% 提到 37.72% [3]。

有趣的是，不同模型「吃」的状态跟踪方式还不一样：有的喜欢填表格式的结构化记录，有的喜欢随便写的自由形式，用错了款式反而可能帮倒忙 [3]。

从软件开发到无人机搜索：验证反馈是关键分水岭

聊了这么多设计原则，你可能会问：那现在哪些领域的智能体交付能力最强？

答案和一个因素高度相关：验证的难易程度。

一篇关于软件开发生命周期的系统综述发现，智能体在软件开发中的采用成熟度，和输出的可验证性直接相关：越靠后的阶段（比如测试、调试），输出越容易通过执行来客观验证，智能体的成熟度就越高、工业应用也越多；越靠前的阶段（比如需求、设计），输出越难客观验证，就还停留在学术概念验证阶段 [6]。

软件之所以是智能体落地最深的领域，本质上是因为它有可执行反馈——写的代码对不对，跑一下测试就知道了，而且测试结果是明确的、可重复的。这种反馈闭环，是「边做边改」范式能成立的基础 [6]。

那其他领域呢？比如无人机搜索。有一篇论文做了用大语言模型引导无人机找东西的工作，它的反馈来自空间语义：无人机能看到环境里有什么物体，LLM 再根据这些物体和目标的语义相关性，决定先搜哪片区域。比如找香蕉，传统割草式搜索可能要把整个房间扫一遍，而 LLM 听到「在餐厅区域」后直接飞到餐桌附近绕圈检查，路径长度减少了一半还多 [4]。

虽然无人机的反馈不像软件测试那样精确可执行，但它有空间语义反馈——看到什么物体、在什么位置，这些都是可以持续更新的观察。这比完全靠人来打分的领域，又进了一步 [4]。

这条路从哪来：从辅助工具到自主交付的演进

智能体式创建不是突然冒出来的，它有一条清晰的演进路径。

最早，AI 只是软件开发各个阶段的辅助工具——帮你补全代码、帮你写测试用例、帮你找bug。每个工具都是单点的，只管自己那一块 [6]。

然后，人们开始意识到，代码本身可以作为智能体的「基础设施」——不只是生成的目标，也是推理、执行、验证的操作载体。这就是「代码即智能体基础设施（Code as Agent Harness）」的思路：用代码来定义智能体的接口、记忆、工具调用，甚至多智能体之间的协调 [7]。

再往后，就出现了能自动构建多智能体系统的框架——比如前面提到的 Meta-Agent，你给它一个自然语言任务描述，它能自动把任务拆成有向无环图，给每个节点生成智能体规范和验证标准，还能在构建阶段和执行阶段都做验证 [8]。

从单点工具，到代码作为基础设施，再到自动构建多智能体系统——整个领域正在从「帮你做某一步」，走向「帮你交付整个成品」 [6][7][8]。

现在的评估，可能连「同题同答」都做不到

讲了这么多进展，也得泼点冷水：现在这个领域的评估，其实还非常不靠谱。

最核心的问题是**学习型评判器（Learned Judge）**的独立性问题。现在很多智能体评估都是用另一个大模型来当裁判打分，但综述指出，如果评判器和生成器共享偏好或盲点，那它几乎提供不了什么独立证据——相当于自己考自己 [1]。

还有更基础的问题：可追溯性。前面提到的 OpenClaw 和 NanoBot 的对比里，同样 23 道题，在两个不同的证据层里，OpenClaw 有 34.8%、NanoBot 有 43.5% 的题目结果等级变了 [2]。你不知道是因为重跑了、环境变了还是打分变了——因为没有完整的执行轨迹记录。

连「同一道题两次测结果不一样」这种最基本的问题都还没解决，那些动辄百分之几十的成功率数字，其实水分很大。

综述甚至直接给出了一个方法论层面的要求：评估协议必须明确把目标、标准、证据渠道、评估者这四样东西关联起来，这样的结果才有可比性 [1]。

三个还没解决的根本问题

最后，我们来看看这个领域最根本的开放问题。综述总结了三个还没解决的核心挑战 [1]：

第一个是可控性与问责。随着制品和系统越来越复杂，怎么保持连贯、可问责的控制？现在的智能体系统，做着做着就可能跑偏，出了问题也不知道该怪哪一步。当系统从做一张海报变成做一个完整软件，这个问题会指数级放大 [1]。

第二个是故障诊断与多解场景。有些故障很难诊断——你知道结果不对，但不知道为什么不对；还有些场景本来就有多个合理答案——不是所有问题都像软件测试那样非对即错。这种情况下，「边做边查」的范式怎么运作？怎么定义「对」？怎么修复？这些都还没有好的答案 [1]。

第三个是评估的独立性。前面提到的学习型评判器和生成器共享盲点的问题，本质上是评估独立性的问题。如果我们连「谁来监考」都解决不了，那所有的性能数字都得打个问号 [1]。

如果你只记住一件事

AI 要从「生成碎片」走到「交付成品」，核心是建立有状态、可验证、能修复的闭环。一次性生成再厉害，也抵不过「边做边查、错了就改」的工程化流程——而这个流程的每一步，从状态表示到验证反馈，再到评估方法，都还有大量基础问题没解决。

参考文献

  1. Agentic Artifact Creation: Systems, Evaluation, Principles, and Opportunities（arXiv、2026、全文精读）
  2. Resource Constraints and Performance in Agentic AI Systems（arXiv、2026、全文精读）
  3. Benchmarking General Mobile Assistants in Challenging Real-World Scenarios（arXiv、2026、全文精读）
  4. Spatial-Semantic Reasoning using Large Language Models for Efficient UAV Search Operations（arXiv、2026、全文精读）
  5. Load-Bearing Context: The Question Damage Score for Evaluating Context Reliance in Linguistic Reasoning（arXiv、2026、全文精读）
  6. Assistance to Autonomy: A Systematic Literature Review of Agentic AI across the Software Development Life Cycle（arXiv (Cornell University)、2026、仅摘要）
  7. Code as Agent Harness（arXiv (Cornell University)、2026、仅摘要）
  8. Meta-Agent: From Task Descriptions to Verified Multi-Agent Systems（arXiv (Cornell University)、2026、仅摘要）