用户到底省了多少事？——从「折叠子 Agent」谈 AI 办公产品的价值

本文是对 Anthropic《Building agents: When to fold subagents into your main agent loop》一文的思考与延伸。 原文：https://claude.com/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop

核心问题：当模型已经能承担更多工作时，我们该怎么重新设计产品，才能让用户实际受益？

最近我看了 Anthropic 的一篇文章，讲的是怎么把一部分子 Agent 的能力，收回到主 Agent 里面。

这个方向，我其实是认可的。随着模型能力变强，以前需要拆成好几个环节才能完成的工作，现在确实有机会交给同一个 Agent，让它自己规划、调用工具，再根据结果调整下一步。对于那些前后依赖比较强的任务，这样做可以减少交接，也方便它理解完整的事情。

我觉得，这篇文章还能再往下想一层：当模型已经能承担更多工作的时候，我们应该怎么重新设计产品，才能让用户实际受益？

这里面，我最关心的一件事，就是用户把一个任务交给产品之后，到底还有多少活，需要自己回来收拾。

我们拿一个具体的办公场景来说。假设你要做一个会议助手，用户希望开完会之后，系统帮他整理结论、提取待办，确认谁负责、什么时候完成，然后把这些任务放进团队实际使用的协作系统里。

这个需求听起来很清楚，对吧？

做方案的时候，你可以把它拆成一个纪要 Agent、一个待办提取 Agent、一个负责人识别 Agent，再加一个检查结果的 Agent。这些能力当然都有用。但我会接着问：把它们分别做成 Agent，具体解决了什么问题？

因为这几件事，很可能都依赖同一场会议里的信息。

比如，会议前半段说，这个功能周五上线。讨论到后面，大家发现数据还没验证完，于是又改成了周五先交验证结果，正式上线时间另定。

你看，这个时候，提取待办需要理解的是整个讨论发生了什么变化。前面有人提出过什么，后面哪些内容被推翻了，最后留下来的决定是什么。

如果每个环节只拿到上一个环节的一份简短总结，就有可能漏掉这个变化。让同一个 Agent 同时看到前面的讨论和后面的修改，它就有机会把这些信息放在一起判断。

所以，这个场景里，我愿意尝试把一些能力合到主 Agent 里。理由很具体：这些工作需要共享上下文，少一次信息转述，就少一次丢失关键条件的机会。

但最终待办有没有正确写成“周五交验证结果”，上线时间有没有保留为待确认，还是要拿结果来检查。架构给了它更好地理解任务的条件，效果需要另外验证。

当然，工作也有适合分开的时候。

比如，你需要同时研究三家供应商，每一家都要读大量材料，各自的调查又相对独立。那么，让几个 Agent 分别处理，再把有依据的结果交回来，就有它的价值。

我觉得，我们在这里要建立的判断习惯是，沿着信息之间的依赖关系去设计工作。哪些事情必须放在一起理解，哪些事情可以独立完成，要先说清楚。把这个问题想清楚以后，拆分和合并才有依据。

再往下，我们还会遇到另一个问题：既然同一个 Agent 能自己规划，产品是不是就可以少管一点？

这里要把“它能够灵活安排工作”和“它可以决定所有事情”分开看。

还是刚才那个会议助手。它可以自己判断先整理结论，还是先查项目资料；也可以根据会议内容，调整待办的分类方式。这些地方，给模型一定的自主性是有价值的。

但创建任务的时候，系统必须检查用户有没有对应项目的操作权限。会议材料里涉及的信息，能不能让某个人看到，也要有实际的权限检查。如果产品规定某类任务需要确认后才能分配，这个条件就应该在提交时被检查。

这些要求，不能只放在提示词里，期待模型每一次都记得。

文章其实也明确提到了，要把校验、审批这些硬限制放到工具和运行框架里面。我认可这个思路。模型负责理解和组织工作，系统负责落实那些不能跳过的条件。

这会直接影响我们怎么写需求。

你写“系统应当正确识别负责人”，这个要求还不够。你得继续想，会议里如果只说“小王跟一下”，团队里又刚好有两个小王，产品怎么办？会议没有明确截止时间，任务里要怎么显示？有人先答应负责，后面又调整了分工，最后应该采用哪一条信息？

这些情况，才是产品真正落地时需要面对的东西。

我的判断是，信息不足的时候，产品应该把不足暴露出来。负责人不明确，就标记为待确认；截止时间没有说，就保留为空，或者请用户补充。让用户看见系统掌握了什么、还缺什么，后面的操作才有基础。

如果为了让输出看起来完整，模型自行补上一个负责人、再补上一个日期，这份结果可能很漂亮，但用户要承担检查这些内容的成本。

这就回到了我前面说的那个问题：用户到底省了多少事？

我觉得，这是做办公类 AI 产品时特别值得认真想的一层。

系统生成了一份纪要，里面有结论、有负责人、有截止时间，从演示的角度看，功能已经做出来了。但用户真正开始用的时候，可能还要重新打开录音，逐条确认它有没有听错；确认完之后，再把内容复制到任务系统里，重新找人、重新填日期。

你看，这个过程中，AI 完成了一部分工作，但用户剩下的工作依然很多。

所以我在评审这个产品的时候，会把整个过程拉长来看。从会议结束，到用户确认任务已经正确进入协作系统，这一整段过程里，用户花了多少时间？修改了多少内容？遇到错误的时候，能不能很快找到对应的原话？任务创建失败以后，需要用户从头重做，还是产品能接着处理？

这些问题，会比单看“生成得快不快”，更接近这个产品的实际价值。

这里还要补一句，人工确认本身是可以有价值的。

有些事项本来就应该由人来决定。比如，一项任务涉及谁来承担责任，或者某个截止时间需要团队达成一致。产品把相关信息整理清楚，让人用更少的精力完成确认，这同样是帮助。

我会比较警惕的是另一种情况：系统没有把自己的不确定之处说明白，最后只能笼统地让用户“请仔细核对全部内容”。

这样一来，用户面对的还是一整份需要重新检查的材料。他很难知道哪些地方值得信任，哪些地方要重点看。

所以，产品应该尽量把需要人判断的地方收拢起来。把依据放在旁边，把冲突指出来，把缺失的信息标出来。用户回来处理的时候，能直接进入那个真正需要他做决定的位置。

我觉得，这比单纯追求所有步骤都自动完成，更值得花功夫。

那么，这些判断怎么变成一个可以推进的产品方案？

在改架构之前，我们可以先拿出一组真实任务，把当前产品的表现留下来。

就以会议助手为例，可以放进一场中途修改结论的会议，一场负责人表达模糊的会议，一场没有明确截止时间的会议。还可以看看，用户在确认待办的时候临时改了要求，产品能不能接着处理。

然后，你再去尝试合并某个 Agent，或者把原来单独的能力变成一份工作说明和一组工具。

测试的时候，尽量固定模型、数据和其他条件，一次改动一个关键部分。这样你才能判断，效果变化到底来自哪里。

我会尤其关注那些原来做对了、改完以后反而做错了的任务。

因为一个方案整体变快了，并不代表每一项重要能力都保住了。假设会议助手生成速度提高了，但开始漏掉会议后半段的决策变更，这个变化就需要单独处理。总分上升，也不能替这类具体问题作解释。

同一个任务，也需要重复跑。只成功一次，能说明这一次做成了，还不足以让我们判断它是否稳定。

文章提到，可以先用十个金标准样例起步。我觉得这个建议对推动团队开始做评测，是有帮助的。但“起步”后面还有工作：继续补充实际使用中发生的错误，把新发现的业务边界加进去。

模型版本变了，工具改了，团队的工作规则变了，这些任务也需要重新检查。评测要跟着产品一起维护，才能持续帮助我们做决定。

这里还有一件事，我觉得也不能忽略。

当你把一个 Agent 变成一份技能说明、一组工具，原来藏在它里面的业务知识，依然需要有人负责。

比如，会议助手应该按什么规则区分“有人提出的建议”和“团队已经确认的决定”？任务负责人怎样对应到系统里的实际账号？项目更换了负责人以后，规则由谁更新？错误进入了正式任务系统以后，由谁接手处理？

这些事情，不会因为架构简化就自动消失。

所以我理解的简化，是减少重复的模型调用、没有必要的信息转述，以及难以维护的中间环节。同时，该保留的业务规则、权限检查和责任分工，要把它们放到明确的位置。

业务团队可以继续负责自己最熟悉的规则和知识，统一的产品团队负责整个任务能不能顺畅完成。每个部分都有人维护，整体效果也有人负责，这个产品才有继续迭代的条件。

回到这篇文章，我认可模型能力增强以后，我们应该重新检查过去的设计。有些拆分在当时是合理的，到了新的模型上，可能已经可以合并；有些步骤以前需要人盯着，现在可以交给系统继续完成。

这些进步，我们应该主动去用。已经投入过的设计，也可以根据新的结果调整。

但我会要求自己说清楚，每一次调整给用户带来了什么。

用户少做了哪一步？哪一类错误变少了？等待时间有没有缩短？需要人工接手的时候，信息是不是完整的？出了问题，能不能找到原因，继续把事情处理完？

接下来做 AI Agent 产品，我们作为 AI 产品经理，需要具备的，就是把模型能力、业务流程和用户收益联系起来的判断能力。

模型能够自主处理哪些工作，哪些条件需要系统强制检查，什么情况下应该让人回来做决定，这些都需要我们理解业务之后作出安排。模型能力继续增强的时候，我们也要能判断，原来设计的流程里，哪些部分还值得保留，哪些部分已经可以调整。

学习一个新框架，了解一种新架构，当然都有价值。接下来还要把它放回一条真实的工作流程里，说明它为什么适合这里，它改善了什么，以及哪些条件还需要系统和人来负责。

放到实际工作里，我们可以先拿出一个正在做的 AI 功能，从用户提出需求开始，一直走到结果真正被使用。

比如，就把一场会议里的那句“周五先交验证结果，上线时间另定”，一路追到任务系统里。看看它有没有被正确理解，负责人有没有确认，日期有没有乱填，用户有没有权限，最后还需要手动补多少工作。

先把这一条任务走完整。走完以后，再决定哪些能力适合交给主 Agent，哪些工作值得独立处理，哪些条件必须由系统检查。

我愿意让模型承担更多工作，也愿意根据新的能力重新设计产品。用户把事情交过来以后，产品能把它推进到什么程度，在哪个位置需要人回来做决定，我希望自己始终说得清楚。