把任务发给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小时内完成资料搜集、分析、撰写、校验全流程还能保持前后口径统一这种稳定性和速度确实是传统人力团队很难复制的。但前提是你得先把目标定义清楚、把工具配到顺手、把检查点埋到关键位置。这些准备工作花掉的时间恰恰决定了自动化跑起来之后能省下多少时间。
