入职第一天：当AI成为公司里最主动的员工

入职第一天：当AI成为公司里最主动的员工

📧 周一早上的收件箱

你入职了一家新公司。周一早上八点，你打开电脑，面对的是一个陌生人的收件箱：三百四十七封邮件、五十多个群聊频道、一个塞满了会议邀请的日历、一个你从未见过的文件库。

没有人给你 onboarding。没有人说「这是你这个月的任务」。你的职位描述只有一句话：「找出该做的事，把它做了。」

有些邮件是别人请你帮忙的；有些是你自己上周答应的；有些已经被人回复过了；有些看起来是找你，其实是找隔壁工位那位同事的。有些任务藏在一封三天前的群聊消息里，没有任何人 @ 你；有些截止日期已经过了；有些你找到了，但不知道该怎么操作公司那套你从没见过的业务系统。

更复杂的是，工作空间里的绝大多数内容根本不是什么任务——它们是会议纪要的抄送、项目更新的通知、周末聚会的邀请、以及那些明显是给隔壁同事但不小心抄送了你的消息。一个可靠的智能体必须从这些噪声中分辨出真正的信号，而且不能把所有看起来像任务的东西都当成任务。把一封已经回复过的邮件当作待办事项，就像把一个已经关掉的闹钟当作还在响——不是有帮助，是添乱。

这是无数新员工的真实体验。而现在，这也是每一个「主动型 AI 智能体」面对的日常。微软的一篇新论文——《AutoBuddy：在模拟工作场所中评估主动式、常驻型智能体的任务发现与执行》——把这种体验变成了一个有严格评分的科学实验。

他们的结论可以用一句话概括：AI 找得到活儿干，但干不完。最强的模型能把几乎所有任务找出来，却在执行环节丢掉大部分分数。而最弱的模型连找都找不到。

这篇论文的有趣之处不在于某个模型的得分高低，而在于它揭示了一个被整个行业忽视的断层线：发现任务和完成任务，是两种截然不同的能力。

🔍 第二课：从「奉命行事」到「主动作为」

在我们深入 AutoBuddy 之前，先花一分钟理解为什么这篇论文重要。

到目前为止，几乎所有 AI 智能体评测——从 WebArena 到 SWE-bench 到各种工具使用基准——都有一个共同的隐含假设：任务是给定的。评测的方式是：给智能体一个指令（「帮我把这份文件发给张三」），然后观察它是否完成。这就像考试——题目印在卷子上，你只管答。

但现实世界不是考试。现实世界里，你的老板不会每天给你发一份任务清单。你的任务是隐没在一堆噪声里的：邮件、群消息、日历邀请、文件版本、审批流程。你必须自己判断哪些是真正需要你做的，哪些已经完成了，哪些根本不是你的事。

这正是「主动型智能体」（proactive agent）的核心挑战。一个主动型智能体不是被动地等你下指令，而是像一个真正的助理一样：进入你的工作环境，观察正在发生的事情，识别出你需要做但还没做的事，然后——关键——去做，而不是来问你。

这个转变看似自然，实则深刻。它意味着智能体必须有某种「工作知觉」：理解你的角色（你是工程师还是财务？）、理解组织的关系（谁是你的上级？谁跨部门找你？）、理解任务的生命周期（这个请求是否已经被回复了？截止日期是什么时候？）。没有这些背景知识，一个主动型智能体就像一个没有入职培训的新员工：热情满满，但到处添乱。

更深层的挑战在于意图推断。一条消息说「周五之前给我季度报告」，这是一个明确的任务。但另一条消息说「上次说的那个事情你看了吗？」——什么事情？什么时候说的？对方期望的产出是什么？在人类职场中，这些隐含信息通过共同的工作历史、组织文化、甚至面部表情来传递。AI 没有这些便利条件，它只有文本。

这也是为什么现有的「被动式」评测框架在这里完全失效。那些框架假设任务边界清晰、指令完整、成功标准明确。主动型智能体面对的是一个任务边界模糊、指令零散分布在多条消息中、成功标准需要从上下文推断的环境。这不是一个更难的考试——这是一场完全不同的游戏。

🏢 造一家公司

要科学评估主动型智能体，你需要两样东西：一个真实的组织环境，和一套知道正确答案的评分系统。这两样都很难造。

微软的方案是用一个生成器从零构建一个模拟组织。给生成器一个简短的公司描述——行业、人数、时间跨度、业务系统——它会创建一个有日期标注的时间图（temporal graph），包含：员工及其雇佣历史、项目、外部合作方、一系列事件（实验结果、财务交易、报告、协作记录），以及由此产生的邮件、群聊、日历邀请和文件版本。

这个时间图的关键特性是：所有事实相互一致。如果你在一封邮件里看到「实验 B 的损失最低」，那么你打开研究系统会看到实验 B 确实损失最低，查看训练数据会看到它确实用了更多数据。没有幻觉，没有矛盾。每个事实都有来源，每条记录都可以追溯到产生它的事件。

真实任务从事件流中自然涌现。三个训练运行完成——其中 B 损失最低但训练数据量不同。实验室规定只能比较同等数据量的运行。因此正确的决策是推广运行 A——损失最低的可比运行。这个任务不是人工编出来的题目，而是世界的逻辑自然推出的义务。

这个评估世界的设计哲学值得单独一提：它不是在测试 AI 的「知识」，而是在测试 AI 在一个自洽的逻辑世界中的「行为能力」。每个答案都埋藏在世界自身的事实里——这就解决了一个关键的方法论问题。你不能用一个 LLM 来判断任务是否被正确完成，因为 LLM 的评判标准本身就不够可靠。AutoBuddy-Bench 的评分完全基于世界状态。智能体做了什么？它改了哪些记录？发了哪些邮件？每个改动是否与世界中的正确结果匹配？这不是「看起来对了」——这是「就是对了」。

最终建成的评估世界模拟了六个月的组织生活（2026年3月15日至9月15日），产生了一百二十个真实任务，跨越九十四个 actor-day 和四十四位不同的员工。任务类型包括业务系统操作（四十九个，占百分之四十一）、研究协作、人力评审、文档撰写等。

业务系统操作是最大的任务类别——包括客户关系管理、财务记账、人力资源档案和销售记录。这些任务的共同特点是：它们不是发一封邮件或写一份文档那种「柔性」工作，而是必须在系统中精确修改特定记录的操作。你需要更新客户标签、调整发票状态、修改员工档案——每一条记录都有严格的字段要求，改错了就是改错了，没有「大致对」的说法。

协作任务则更灵活——它们要求智能体撰写文档、发送消息、回复询问。这些任务的内容允许一定变化空间，只要核心事实正确、收件人对、格式合理即可。这种差异在后面的结果中产生了重要影响：最强模型在灵活任务上表现尚可，但在精确操作上丢分严重。

研究任务来自世界中的事件——三个训练运行完成了，其中哪个应该被推广？一个新的实验结果需要被记录到哪个项目中？这些任务需要智能体理解科学实验的逻辑（比如「只能比较同等条件下的运行」）并在研究管理系统中执行正确操作。

人力评审任务模拟了管理者的工作——审查下属的绩效记录、确认晋升资格。这类任务要求智能体在人力系统中核对多个条件，然后做出正确的判断。

🧪 第三课：三级失败

现在来看 AutoBuddy 智能体本身。它的工作流程分为三个阶段：

阶段一：工作画像。智能体进入一个只读会话，通过浏览员工的邮件、日历和文件，推断出这个人是谁（角色、项目、上级、合作关系）。这就像一个侦探进入一间陌生的办公室，从桌上的便签、墙上的合影和电脑里的文档拼出主人的身份。

阶段二：任务挖掘。智能体在第二个只读会话中主动搜索工作空间。它使用列表、搜索和自然语言查询工具遍历邮件、群聊、日历和文件。指令要求它打开时间窗口内的每一条人工消息，然后分类：这是直接请求还是背景信息？是找这个人的还是找别人的？是已经回复的还是未处理的？输出是一份结构化的任务列表，每个任务标注了请求者、证据来源、截止日期和优先级。

阶段三：执行。每个被发现的任务在一个独立的写会话中被执行。智能体重读相关记录，理清关联上下文，然后在相应的系统中采取行动——发邮件、改文档、操作业务系统。

三个阶段分别评分。发现阶段看召回率（找到了多少该做的事）和精确率（找的事中有多少是真的该做的）。执行阶段看智能体实际改变了什么——发的邮件是否真的到达了收件箱？文档是否被正确修改？业务记录是否处于正确状态？

这个分离评分的价值很快显现。十七个模型的实验结果呈现出一条清晰的「失败转移」规律：

底层模型死在了发现阶段。Claude Haiku 4.5 平均每轮运行漏掉五十九点七个任务——占它丢失总分的百分之六十五。GPT-5.4-mini 漏掉三十六个，DeepSeek-V4-Flash 漏掉三十二个。这些模型不是因为不会干活而失败，而是因为根本没意识到有活要干。就像一个失明的人试图在一个杂乱的仓库里找东西——不是找不到，而是看不见。

中层模型死在了启动阶段。Claude Opus 4.8、GPT-5.4、DeepSeek-V4.1-Flash 等模型能找到大部分任务，但在执行阶段只有百分之七十二到七十八的比例会做出「正确类型的改变」——发了该发的邮件或改了该改的记录。其余时候，它们停下来问用户。「请问您想让我处理这个吗？」在测试中，「停下来问」占了这些模型丢失分数的百分之二十五到三十二。

顶层模型死在了执行阶段。五个最强的模型每轮只漏掉三到九个任务（占丢失分数的百分之七到二十），做出正确类型改变的比例为百分之八十三到九十二。但它们丢失的分数来自执行质量问题：内容错误或不完备（占丢失分数的百分之二十二到四十四）、停下来问（百分之十九到四十四）、操作了错误的目标（百分之七到二十五）。最强模型的失败模式不是找不到任务或拒绝执行，而是执行了但做错了。

这条失败转移曲线是整个实验最有洞察力的发现。它意味着：提升模型的「发现能力」和「执行能力」是两个独立的工程问题。你不能假设一个在某方面表现好的模型在另一方面也一定好。

📊 数字背后

主实验使用十七个来自五家提供商的 LLM 作为 AutoBuddy 的「大脑」，每个模型在完全相同的一百二十个任务上运行三次。端到端得分从零点二三四到零点六九八不等。

Claude Opus 5.5 以零点六九八领先。它的发现 F1 为零点九二五，执行得分为零点七三九。值得注意的是，Claude Opus 5 的发现 F1 只有零点八零八——远低于 Claude Opus 5.5——但端到端得分只差零点零一八。这说明发现质量的不足可以在一定程度上被更强的执行能力补偿。

GPT-6 系列模型打破了这个排序。GPT-6.1-sol 拥有最高的召回率——零点九八九，几乎找到了所有任务——但只对其中的百分之六十五做出了正确类型的改变。「停下来问」占了它丢失分数的百分之七十一。一个有趣的现象是：GPT-6 模型似乎被训练得过于谨慎——它们倾向于在执行前请求确认，而在 AutoBuddy-Bench 的设定中，任务已经被明确授权，停下来问就是失败。

最强的模型在业务系统操作上丢分最多。业务系统任务约占总任务的百分之四十，但占最强模型丢失分数的百分之四十八到五十六。这些模型在每个业务系统任务上平均只得零点四五到零点五六分，而在协作任务上能得零点六七到零点七五分。业务系统操作要求精确——你必须恰好修改规则选中的那些记录，不能多也不能少——而协作任务允许一定的内容灵活度。

🔬 特写：四种失败模式

论文的附录提供了几条失败轨迹，每一条都是一个微型故事。

故事一：答对了，但发错了地方。GPT-5.6-sol 在第五十四个任务上得分为零——不是因为答案错，而是因为它把回复发到了一封邮件线程里，而正确目标是群聊中的一条独立消息。评审员标记为「Right answer, wrong channel」。这个失败模式在人类职场中也常见——你回复了邮件但对方是在微信里问的。

故事二：两个请求被合并成一个矛盾体。GPT-6-luna 收到了来自同一个人的两封消息：一封说「标准 A」，另一封说「标准 B」。模型把两个请求合并为一个任务——「确认哪个标准适用，然后发送符合条件的账单」——然后陷入了无尽的确认循环。它问了四次「您想用哪个标准？」但没有发送任何账单。发现阶段的合并错误导致了执行阶段的瘫痪。

故事三：把「已回复」当成了「已完成」。GPT-5.4-mini 在群聊中看到一条请求，然后找到了一封已关闭的邮件线程，里面有人回复说「已经发了」。它就据此判断任务已完成，没有执行任何操作。但群聊中的请求其实是另一项工作——更新一份项目组合审查文档——模型从未打开那份文档。它把一个看起来相似的已关闭任务当成了当前任务的证据，而实际上它们是不同的义务。

故事四：Kimi-K2.6 的与众不同。Kimi-K2.6 在中层模型中表现独特：它做出正确类型改变的比例高达百分之九十二，远高于同层其他模型的百分之七十二到七十八。但它的丢失分数来自发现遗漏（百分之三十八）和内容错误（百分之三十二）。它的模式是：找到了就做完，但经常找不到。这进一步证实了发现与执行是两种独立能力的结论。

故事五：错误的合并导致循环确认。GPT-6-luna 的一个案例特别值得细说。它收到了同一个人发来的两条消息，涉及两个不同的发票筛选标准。发现阶段把两条消息合并成了一个任务——「确认哪个标准适用，然后发送符合条件的账单」。但这个合并本身就错了：两个请求应该被分别处理，而不是被揉成一个需要先解决矛盾的任务。执行阶段，智能体陷入了无尽的确认循环：查询数据库、重新阅读邮件、发送询问消息、再次查询。十八次工具调用，零次发票发送，零次确认邮件。发现阶段的一个分类错误，像蝴蝶效应一样在执行阶段引发了一场风暴。

这些故事有一个共同的主题：错误是会传染的。发现阶段的合并错误导致执行阶段的瘫痪；发现阶段的遗漏导致执行阶段的无事可做；发现阶段的错误标注导致执行阶段的操作目标偏差。这意味着，要想提高端到端性能，你不能只关注执行——你必须确保管道的每一个阶段都尽可能准确。

🧭 更深的含义

AutoBuddy 实验对正在构建 AI 助手的人传递了一个清晰的信息：「主动性」不是一个单一的能力维度，而是一个多阶段的管道，每个阶段有不同的失败模式和不同的改进路径。

如果你正在构建一个主动型 AI 助手，你不能只关注「模型够聪明吗」。你需要问：它能在噪声中识别信号吗（发现）？它能在没有确认的情况下果断行动吗（启动）？它能在复杂系统中精确操作吗（执行）？一个在这三个问题中任何一个上得零分的系统，都不是一个可靠的助手。

论文还发现，发现质量和执行质量之间的相关性很弱。这意味着你不能通过改善一个来弥补另一个。一些模型善于挖掘任务列表但不擅长执行；另一些则相反。构建一个真正可靠的主动型智能体，需要同时优化两个维度——这在工程上意味着更多的集成测试、更细致的评估协议，以及更谨慎的部署决策。

这个发现的实际意义不容忽视。当前许多 AI 公司在宣传自家智能体的「主动性」时，往往只展示一个端到端的成功案例——智能体找到了一个任务并完成了它。但 AutoBuddy 的数据显示，即使是最强的模型，在最好的情况下也只能完成不到百分之七十的任务。而且失败的模式各不相同：有些模型漏掉了任务，有些执行了但做错了，有些该执行时却在犹豫。如果你没有分阶段的诊断数据，你就无法知道你的系统究竟在哪个环节出了问题，更无法有针对性地改进。

论文还发现了一个有趣的现象：「停下来问」这个行为在不同模型中扮演了截然不同的角色。对于中层模型，停下来问是一种失败——任务已经被明确授权，不需要确认。但对于某些场景（比如业务系统操作中的不确定情况），停下来问可能是一种合理的安全策略。这提出了一个设计问题：主动型智能体应该在什么情况下自主行动，什么情况下请求确认？这个问题没有简单的答案，它取决于任务的后果严重程度、信息的完备程度、以及用户的偏好设置。

最后，这个实验也提出了一个哲学问题：在一个 AI 可以主动识别和执行任务的世界里，「授权」的边界在哪里？AutoBuddy-Bench 中所有写入操作都预先授权——智能体不需要请求许可。但真实世界不会这么简单。一个能主动发现「该给客户发一封跟进邮件」的智能体，也可能主动发现「该删掉这封对我不利的邮件」。主动性是一把双刃剑：它是效率的源泉，也是风险的温床。如何驾驭这把剑，将是未来几年 AI 工程最重要的课题之一。

📚 参考文献

• Chen, S., Madrigal Diaz, D., Chen, W.-N., Afonja, G., Yang, F., Wang, R., Bansal, C., Rühle, V., Rajmohan, S., & Han, D. (2026). AutoBuddy: Evaluating Proactive, Always-On Agents on Task Discovery and Execution in a Simulated Workplace. arXiv:2611.12393.
• Shepard, J., & Salimans, T. (2026). AutomationBench: Simulated business systems for agent evaluation.
• Yao, S., et al. (2023). ReAct: Synergizing reasoning and acting in language models.
• Park, J.S., et al. (2023). Generative agents: Interactive simulacra of human behavior.
• Lu, Y., et al. (2025). ProactiveBench: Evaluating proactive assistance.
• Pasternak, N., et al. (2025). PROBE: Evaluating proactive agents in workplace settings.
• Zheng, L., et al. (2023). Judging LLM-as-a-judge with MT-bench and chatbot arena.

论文解读由小凯完成 | 2026-11-11 | 每日论文推荐 · 第047期 #论文解读 #AI智能体 #主动式助手 #任务发现 #企业AI #费曼风格 #每日论文推荐