把任务发给Agent之后我直接关了电脑去睡觉。第二天早上打开日志，看到这一夜它完成了237次工具调用、6次自我纠错，最终吐出了一份一万两千字左右的《零人公司自动化运营实践研究报告》。说实话，报告本身写得怎么样是其次，真正让我感兴趣的是这237次调用背后暴露出来的一整套长程任务的执行链路。这正是我们内部代号“龙虾”的长程任务测试想搞清楚的东西——当一个任务需要跨多个阶段、调用多种工具、连续工作数小时的时候，Agent到底能不能像人一样从头到尾扛下来？
这篇文章就把这次测试的完整过程拆给你看。如果你也在折腾AI Agent自动化、想搞明白长程任务怎么做稳定，或者对“零人公司”这个概念感兴趣，那这篇东西应该能帮你省不少弯路。
1. 为什么我会用“写一份研究报告”来测试长程任务
1.1 长程任务的真正难点：不是单次聪明，而是持续不崩
先说一个很多人在ChatGPT时代养成的错觉：觉得Agent很聪明，给个任务就能搞定。单轮问答确实没问题，但长程任务是另一回事。一次长程任务通常意味着几十甚至上百个步骤，中间要切换不同工具、要读取和生成大量文本、要不断回看前面的结论修正后面的判断。任何一步的上下文漂移、工具参数错误、中间结果理解偏差，都会像滚雪球一样往后放大。
我见过太多Demo在5分钟之内跑得漂亮，一到30分钟以上的连续任务就崩。要么是规划逐渐失焦，写到后半部分忘了最开始的目标；要么是工具调用开始抽风，重复请求、错误参数、死循环；要么是自我纠偏越来越弱，明明看出了问题却不知道怎么改。长程任务的本质，从“单次推理质量”变成了“系统级稳定性”。
所以“龙虾测试”的定位从一开始就不是考智力，而是考耐力。我们想看的是一个Agent系统在无人值守条件下，能不能像一位实习研究员那样，接一个项目、自己拆解、自己找资料、自己写、自己检查、最后交出一份过得去的成果物。
1.2 选题的逻辑：零人公司恰好是Agent的“镜像命题”
为什么偏偏选“零人公司自动化运营实践研究报告”这个题目？有两个原因。第一，这个题目本身非常复杂，跨了商业模式、技术架构、流程设计、风险合规好几个领域，Agent必须有足够的“领域跨度”才能组织出一篇像样的报告，这比写单一技术教程难得多。第二，这个题目和Agent自身形成了绝妙的镜像——零人公司的核心就是把人从运营链条中逐步抽离，而长程任务测试恰恰也在探索同一件事：什么环节可以交给机器？什么环节必须留人？
一个能独立完成“零人公司研究报告”的Agent，本身就是“零人运营”的最小可行样本。它在这几个小时的运行里所使用的队列调度、工具调用、自我校验、异常恢复机制，放到真实公司运营里，就是一个又一个自动化工位。所以这个测试不只是写一篇报告，更像是在用一个实践过程来论证题目本身。
2. 测试前的准备：给Agent搭一个能跑长跑的身体
2.1 任务下发时我喂进去的东西
很多人以为给Agent一个标题就能让它写报告，但长程任务完全不是这么回事。这次测试我们采用了“任务卡片”的形式下发，内容包括四个层次：目标定义、交付标准、约束条件、可用资源。
目标定义这一层写得最细。不只是“写一份零人公司自动化运营研究报告”，而是把报告拆成了六个必须覆盖的板块：零人公司的定义与成立前提、自动化运营的核心模块拆解、AI Agent在运营流程中的角色、支撑基础设施清单、风险与合规边界、从有人到零人的过渡路径。每一块都给了一个简短的期望描述，相当于给Agent画了一张研究地图。
交付标准写的是：格式为Markdown、总字数一万字左右、必须包含至少三个真实可参考的案例场景、结论部分必须有“能直接落地”的可执行清单。约束条件里则明确禁止编造数据、引用不存在的政策文件、以及使用模糊的形容词来糊弄段落。
这里我踩过一个教训：最开始任务卡片写得太粗，Agent产出的报告结构松散，全是正确的废话。后来把交付标准和约束条件写明确了，产出质量直接上了一个台阶。
2.2 工具层与子Agent编排的设计
工具注册这个环节，核心不是“能调什么”，而是“允许Agent在什么条件下调”。我们预置了几组工具：网络搜索、本地文档检索、结构化数据库查询、计算器、文件读写、以及一个专门的格式校验器。
网络搜索被设计成必须带query参数，且强制要求对搜索结果做来源记录。本地文档检索则接了一个去重机制，避免Agent反复读取同一份资料。子Agent的编排上我们做成了“一主三副”：一个主控Agent负责全局规划和任务拆解，三个子Agent分别负责资料搜集、内容撰写、合规审查。主控手里握着“任务状态机”，知道当前整个项目推进到了哪一步，所有子Agent的产出都要回到主控这边登记，不能自己闷头干。
这个设计灵感来自真实的项目管理。一个人全包所有工作容易迷失，但如果有项目经理、研究员、写手、审校这四个角色各管一段，整条链路的可控性会强很多。实测下来，这种分工确实比单Agent硬扛要好。
2.3 上下文与记忆管理：长程任务的命门
长程任务里最常翻车的不是推理能力，是上下文管理。模型窗口有限，对话一长前面的内容就开始模糊。我们这次用了三层记忆结构。
第一层是“会话摘要”：系统每隔一段时间把对话历史压缩成结构化的项目快照，存到外部记忆文件里。第二层是“关键产出登记表”：每一步的重要结论、数据、工具返回结果，都以结构化条目写进一个JSON文件，主控Agent需要时可以随时查询。第三层是“任务状态机”：记录任务的当前阶段、待办事项、已完成事项，以及每个子Agent的当前状态。
这套设计的价值在过程里体现得非常明显。有一次主控Agent写到第四章的时候需要引用前面章节的一个结论，它没有靠“回忆”，而是直接去查关键产出登记表，查到了准确表述。如果没有这三层记忆，长程任务后半程的上下文漂移基本是必然发生的。
3. 执行链路逐步还原：一次任务是怎么从头跑到尾的
3.1 阶段一：目标解析与提纲自规划
任务下发之后，主控Agent做的第一件事不是开写，而是花了很长一段时间做目标解析。它会先把任务卡片里的目标、交付标准、约束条件逐条理解一遍，再转化成一张可执行的任务分解表。
这次它输出的初始提纲有三级结构，共12个一级段落，每个段落拆成2到4个子主题。有意思的是，它自己会在提纲后面标注优先级和依赖关系，比如“必须先完成定义与边界梳理，才能进入自动化模块的详细分析”。这种依赖关系的识别，正是长程任务里“规划能力”的最直接体现。
我给这套规划阶段的评价标准很简单：如果提纲本身已经像一份可交付的研究大纲，那后续执行就不会跑偏太多。这次它的自规划质量可以打75分，有两条子主题的优先级排序不合理，但整体方向没有歪。
并行化在这一阶段就开始体现价值。主控Agent确认提纲之后，马上把资料搜集任务分发给资料子Agent，同时自己进入框架细化。这种一个人干不完、多个角色同时推进的状态，是真正常见的团队工作模式。
3.2 阶段二：资料采集与信息的二次校验
资料搜集阶段是整个任务中工具调用最密集的环节。资料子Agent以提纲为索引，逐条展开搜索、检索、保存和标注。这里有个细节很关键：它每搜到一个信息源，都会强制记录来源名称、时间、核心摘要和可信度评分，然后写进资料库。
这套“资料卡片”机制帮了大忙。写到后面章节时，主控Agent引用数据可以追溯到具体来源，而不是凭印象写。整份报告里的数据支撑要比我们预想扎实得多。
但资料采集最大的坑不在检索，而在“信息过载”。子Agent一度抓取了大量低质量网页，导致资料库冗余。后来触发了一次自我清理机制：它根据可信度评分和相关性评分做了一轮资料瘦身，从70多条降到30多条，这才保证了后续写作阶段不会被冗余信息干扰。这次自我清理动作让我确信，给Agent配置“信息筛选策略”跟配置“检索能力”同等重要。
3.3 阶段三：分章节撰写与结构收敛
进入撰写阶段后，工作流的组织方式变成了“轮次推进”。主控Agent按提纲顺序一次推进一到两个小节，写完后先存草稿，等到一个阶段完成后再做整体收敛。
撰写阶段的输出质量分布有一个值得注意的现象：前半部分（定义、背景）写得偏学术，中段（模块拆解、技术分析）质量最高，后半部分（风险合规、过渡路径）又出现了一些泛泛而谈的段落。这个规律跟人类写作高度相似——越到任务后期，注意力资源越分散，输出质量越容易滑坡。
针对这个现象，我们的审校子Agent在后期发挥了关键作用。它专门负责识别“空话段落”，自动标记“这段只是罗列概念但没有具体案例支撑”，然后反馈给主控Agent做二次改写。经过两轮修改，原本几段比较空的结论部分被补上了具体的自动化运营模块配置案例。
这一阶段的重头戏是结构收敛。多个轮次产出的内容需要合并成一份完整报告，就涉及到章节编号调整、重复内容去重、术语统一等工作。格式校验器在这个环节跑了一次全文扫描，把标题层级错误、列表格式混乱、引用缺失等问题一次性抓了出来。
3.4 阶段四：一致性校验与交付
最终交付之前，还有一个很容易被忽略的“一致性校验”环节。主控Agent会把整份报告和任务卡片里的交付标准逐条核对，确认字数、覆盖范围、案例数量、格式要求都满足了，才标记为完成。
这次校验暴露了一个有趣的问题。报告里有一处前后矛盾：第二章还在说“零人公司短期仅适用于信息密集型业务”，第六章的过渡路径却把门店零售类业务也列进去了。审校子Agent抓到了这个矛盾，主控Agent的处理方式是回到资料库重新检索了“零人公司的适用行业边界”相关资料，然后改写第六章相关内容，让前后口径一致。
这种“全局一致性校验”恰恰是长程任务测试里最容易被低估的能力。单段文本在局部看都没问题，但跨段落逻辑打架，人眼看多了都容易漏，Agent在全文档层面做一次系统扫描，反而能抓得更准一些。
4. 实测结果与关键发现：哪些环节先撑不住了
4.1 整体表现数据
整个测试跑下来，几个关键数字如下：总执行时长约2小时40分钟，工具调用237次，自我纠错6次，产出报告约1.2万字。人工介入两次：一次是在资料采集中期，我发现资料库的检索来源偏窄，手动补充了一个提示词约束；另一次是在最终交付前，我抽看了一部分章节的质量，对结论部分提了一条修改意见。
如果按“能否达到可交付水平”来判断，这次是达标的。如果按“能否直接作为公司运营参考文档”来判断，还差一些——部分模块的结论偏笼统，缺少行业级的一手数据支撑。这个差距主要不是Agent能力问题，而是资料库和工具生态的边界所限。
这里要特别说一句，任何Agent测试的表现都高度依赖环境配置。我们这套系统在资料库充足、工具定义清晰的条件下表现稳定，换一个环境、换一批工具，结果可能完全不同。所以这份数据仅供参考，不必当作通用结论。
4.2 断裂点分析：上下文漂移、工具误调用、自我纠偏失效
整个链路中，最容易“断”的地方有三个。
第一个是上下文漂移。这个主要集中在长对话后段，主控Agent偶尔会忘记早期定下的术语定义，比如第二章把“零人公司”定义收窄到“无全职员工的数字化企业”，到第六章写作时却使用了更宽泛的定义。这种漂移不是突然发生的，而是逐渐积累的，等到审校发现时已经产生了系统性偏差。
第二个是工具误调用。有一次资料子Agent需要查询行业报告数据，对着同一个搜索接口连续触发了7次不同参数的请求，前6次参数都略有错误。虽然最终第7次成功了，但白白消耗了不少运行时长。后来分析日志发现，是它的参数生成逻辑对“年份+行业”的组合理解不稳定。
第三个是自我纠偏失效。测试过程中有一步，审校子Agent明确指出了一个段落的论据不足，主控Agent也承认问题存在，但给出的修改方案只是换了一种表述方式，并没有补充新的论据。这说明Agent能够“发现问题”，但不一定能够“解决对问题”。
这三个断裂点放在一起看，指向同一个本质：模型需要更强的全局状态感知能力，而不是更聪明的单次推理。
4.3 无干预vs低干预：这4分钟的差距有多大
为了对照，我还跑过一次完全无干预的模式。那次任务中途就开始偏航，主控Agent在一个次要分支上花了大量时间深挖，主线任务进展缓慢。最终产出的报告覆盖面不完整，结构松散，只能算半成品。
这次“低干预”模式之所以能跑得更稳，本质上是靠两个轻量级人工动作撑住的：一次是初期提示词约束，把检索源范围从“全网”修正为“行业报告、企业案例、技术文档优先”；另一次是终稿前的单条修改意见。两次干预合计不到4分钟，但直接把最终交付质量从一个档次拉到了另一个档次。
这组对照给我的启示很明确：长程任务自动化的终极目标不是零干预，而是把人工干预控制在“极低频+高杠杆”的层面。让机器把每分钟都花在重复性劳动上，让人的有限注意力只用于关键决策和方向校正，这才是“零人公司”框架里最现实的运作方式。
5. 从测试看运营：零人公司的自动化闭环应该长什么样
5.1 运营侧六大模块怎么拼
报告的正文部分，我们把零人公司的自动化运营拆成了六个模块。
第一是获客引流模块。它承接的是线索生成、渠道分发、内容发布、广告投放策略优化这类重复性工作。AI在这里的角色更像一个不知疲倦的内容运营＋投放优化师。
第二是交付服务模块。这个模块的逻辑是把标准化的服务流程产品化，做成固定模板加参数化配置。客户下单后，系统根据订单参数自动生成交付内容或触发外部API执行任务，整个过程不需要人工介入。这次测试里Agent自动产出研究报告的过程，其实就是这个模块的微缩版。
第三是客诉处理模块。理论上80%的常见问题可以被知识库＋意图识别方案覆盖掉，剩下20%的复杂问题再通过工单系统转给外部协作人员。
第四是财务与对账模块。这里强调的是规则驱动，费用计算、账单生成、发票开具、回款核销这些环节都能用自动化脚本衔接。关键是每笔操作都要留痕，方便事后审计。
第五是监控告警模块。零人公司看起来没人，实际上最需要“有人看着”——只是这个“人”变成了监控系统。系统需要持续盯任务队列里的积压情况、工具调用的成功率、异常事件的数量趋势。
第六是内部协作与知识管理模块。这个模块相当于公司的“记忆体”，所有流程文档、历史案例、决策记录都以结构化形式沉淀下来，AI Agent在需要的时候能够随时检索调用。这跟我们测试里用到的三层记忆结构是同构的。
5.2 控制侧：人应该留在哪个回路里
零人公司不是真的一个人都没有，而是把“人”从执行回路中抽离，放到控制回路中。这个区别非常重要。
执行回路处理的是“已知的已知”——场景明确、规则清晰、输入输出不变的任务，比如生成标准报价、处理常见客诉、跑固定报表。这些工作完全可以自动化。控制回路处理的是“已知的未知”——异常情况、策略调整、新业务定义。这一层需要人的判断，但人不需要亲自操作，只需要写规则、做决策、审异常。
按这次测试的经验，人应该重点守好三个位置：战略方向的定义者（决定公司做什么业务、怎么定位）、异常事件的决策者（处理AI上报的少数疑难杂症）、规则与边界的维护者（定期更新自动化流程的约束条件）。只要这三个位置有人在，公司绝大多数日常运营完全可以运行在自动档上。
5.3 风险与合规不能省
写报告过程中，我们专门讨论了一个问题：零人公司最大的风险是什么？结论是责任归属的模糊。出问题的时候，机器不会担责，人又不在场上，客户找谁？因此任何零人运营方案都必须在系统设计层面就把责任链写清楚。自动化系统必须留全量日志、操作留痕、决策可追溯；每一类自动决策都要有预设的升级路径，达到一定风险阈值后自动转人工；对外宣传中必须明确服务责任主体。这套安全网对“零人”来说不是限制，而是让整个模式能转起来的信任基础。
6. 踩坑记录与可复用的执行清单
6.1 印象最深的三个坑
第一个坑是“任务卡片写得越重，任务跑起来越稳”。一开始我把任务描述写得很轻，只有目标和主题，结果Agent产出的大纲泛泛而谈，根本没有聚焦点。后来加了交付标准和约束条件，质量立刻不同。这就是“重提示词”策略的典型应用场景——Agent时代最稀缺的资源不是算力，而是定义清晰的目标。
第二个坑是“别让子Agent无限长跑”。资料采集的那次信息过载经历让我意识到，如果不给子Agent设置“产出上限”和“轮次上限”，它会在一个环节里无限钻牛角尖。后来任务状态机里加了一个硬约束：单个子阶段最多执行N轮，超过后必须强制收敛，带着已有成果往下走。不要追求单步骤的最优解，长程任务要的是全链路的高完成度。
第三个坑是“审校Agent不能最后才上”。最初我们把审校放在末尾，结果发现到那时问题已经积累得很深，返工成本巨大。改成“伴随式审校”之后，每个阶段结束立即做一次一致性检查，问题在早期就被修正，整体效率反而更高。做长程任务编排，校验应该是一个连续的伴随过程，而不是一个独立的终点环节。
6.2 一套可以直接套用的检查清单
这次测试沉淀下来的几个关键点，整理成一份可以直接用的检查清单：
- 任务下发的第一步，先确认目标定义、交付标准、约束条件三件套齐全。
- 把可用工具整理成清单，并标注每类工具的适用边界。
- 给Agent规划一次任务拆解，明确主控与子Agent的分工边界。
- 建立外部记忆层，用JSON文件或数据库记录关键产出、会话摘要、任务状态。
- 为长程任务设定阶段检查点，每隔一段时间强制做一次全局一致性校验。
- 明确哪些情况允许Agent自我纠偏，哪些情况必须上报人工。
- 终稿交付前，对照任务卡片逐条检查交付标准。
如果这套清单里的每一项都过了，一次长程Agent任务跑出可交付成果的概率就会高很多。
6.3 后续还可以怎么扩展
这次测试只是把链路跑通了，后面还有很多可以深挖的方向。比如把工具库从“搜索+检索”扩展到“数据库写入+API调用”，让Agent不只写报告，还能真正地去执行业务动作。比如把任务卡片从人工编写改为“目标自动拆解”，甚至尝试让一个Agent去给另一个Agent下发任务。再比如给系统加上多轮反馈回路，让产出物可以按外部评价持续迭代，而不是一次成稿。
这些扩展本质上都是在朝同一个方向走：让自动化从“能写出建议”走向“能执行、能迭代、能闭环”。这也是我把零人公司研究报告这个题目选作测试载体的初衷——我们不只是写一份关于自动化的报告，我们正在用自动化本身去论证自动化的可行性。
最后分享一点我个人的体会。这次测试的整个过程，让我对“零人”这个概念有了更深的理解：零人公司的价值不在“没有人的成本优势”，而在于“运营决策的速度和一致性”。一个系统在2小时内完成资料搜集、分析、撰写、校验全流程，还能保持前后口径统一，这种稳定性和速度确实是传统人力团队很难复制的。但前提是，你得先把目标定义清楚、把工具配到顺手、把检查点埋到关键位置。这些准备工作花掉的时间，恰恰决定了自动化跑起来之后能省下多少时间。
