作者把一份两人同行、六天五晚的北京旅行方案交给「豆包工作」：先用 Skill 录入旅行方法，再让三个 Agent 并行查资料，最后产出一份可继续修改、便于同行者讨论的行程文档与 PPT。

回顾一下国庆假期。共同出行中负责做攻略的人，要处理的事情通常比找几个好去处更琐碎：酒店离地铁近不近，逛完景点还要走多远才能吃饭，同伴临时想加一个展览，当天原有的安排又该怎样挪动。每个选项都牵动时间、预算和偏好，查到的信息还要被反复比较、解释和修改。

klook 今年 8 月发布的调查覆盖 10 个市场、2,725 名旅行者；在一周团体旅行的讨论语境中，超过七成负责规划的人表示，安排一次旅行要花 10 小时以上。预算、时间协调和机酒比较，都是压力来源。

旅行也成了个人 Agent 检验执行能力的一类场景。Meta 在 9 月发布 Muse 时，把预订旅行列为用途之一，任务可以在带有浏览器的专属云端电脑上执行；Instinct 创始人 Noah Shinn 则在 9 月底的一期访谈中称，旅行约占平台交易额的一半。两者都把产品向一次问答之后的工作推进：找到选项以后，还要能接着处理具体事务。

独立电脑版「豆包工作」也在尝试承接这种连续的工作。它把资料研究、浏览器与电脑操作、表格整理和 PPT 制作放进同一个任务入口，按需要在本地电脑或云端执行；云端任务还可以经手机上的豆包、飞书等入口查看进度、补充要求。

为了看清这条工作链能接到哪里，本次把测试任务限定为一份两人同行的北京旅行方案：12 月 10 日至 15 日，六天五晚，故宫和长城必去，其余景点、住宿和餐饮逐步补齐。这个设定对应的是共同出行中规划者的日常难题，既有明确的时间边界，也要在多个选项之间取舍。测试要看的，是零散的查询能否最后形成一份便于同行者讨论、也经得起继续修改的计划。

先把旅行方法录成 Skill

规划一趟陌生城市的旅行，最初的困难是选择太多，却缺少比较它们的依据。测试从“冬季旅行去北京有哪些景点推荐”开始，「豆包工作」把结果按冰雪、皇家园林、中轴线、胡同、室内和夜景等主题归类，让候选去处先有了一个大致轮廓。

每一个景点都有几项相同的问题：什么时候开放，门票多少钱，是否需要预约，原始信息在哪里。借助「浏览器录制与回放」Skill，用户在网页上示范一次查找和采集，「豆包工作」识别步骤，再沿用这套方法继续查询。

几轮搜集下来，五个景点的名称、简介、开放时间、门票和链接，随后导入飞书多维表格。

选定景点以后，问题转向住在哪里。这次给酒店设置的条件是每晚 400–800 元、评分 8.5 分以上，再结合到景点的距离挑选。价格相近的房间，位置可能差很多；离其中一个景点近，也未必方便去其他地方。

酒店查询同样可以录成 Skill。一次示范之后，「豆包工作」会确认日期、查询范围等条件，后续换一个景点时继续沿用已有方法。最终表里保留了 18 条候选记录，按景点分组，供后面比较。

这一环节呈现出个人 Agent 的一种产品思路：把用户查资料的方法也变成后续任务可以使用的条件。规划者仍然决定预算和位置偏好，工具则尝试接手重复进入页面、提取字段和整理表格的部分。信息有了共同格式和可回查的来源，下一步的选择才不必从一堆收藏链接开始。

把重复执行交给多 Agent

景点和住宿之外，还有一层更细的安排：冬天逛完故宫，愿不愿意再走一段路吃饭；去长城要带哪些防风衣物；留给 798 的半天能看什么展。这些问题分散在不同页面里，也适合拆开处理。

餐厅查询用到了“操作电脑” Skill。选好技能后，交代搜索范围、人均预算、评分和每组数量，「豆包工作」便在 Mac 图形界面中打开网页、搜索并筛选。测试的目标是每个景点找 3 至 5 家、人均 200 元以下、评分 4 分以上的餐馆。

餐饮表最终留下 13 条记录，包含店名、地址、口味、环境、服务、人均消费和招牌菜。它把原先要逐个翻看的信息集中起来，让人可以围绕当天路线比较去哪一家；至于两个人想吃什么、愿意为一顿饭绕多远，仍然需要共同决定。

行前准备、五个景点的打卡与购票事项、798 展览信息，则由三个 Agent 并行研究，各自产出文档，再汇总成索引。这样可以把不同方向的搜集同时推进，规划者再集中查看结果。

行前准备从历史同期的气温、风力延伸到衣物和日用品；景点资料补充预约与打卡信息；展览资料则整理场馆、展期和购票方式。距离出发还有一段时间，天气可以先用于判断穿衣的大致需求，临近出行时再看具体预报。

这组资料查询在云电脑中展开，前面的餐馆查询则使用了本地电脑。两种执行环境参与同一项旅行准备。按产品支持的用法，外出时也可以通过手机查看云端任务、补充要求，回到电脑后继续处理文件。

先筛选，再直接做成 PPT

资料越齐，接下来越需要做取舍。让 Agent 把时间、预算、偏好和目的地条件放到一起比较，排除不适合的选择，「豆包工作」先会生成初步计划，需要修改的可以继续沟通，收敛出少数几个值得讨论的方案，最后得到一份比较详细的行程计划文档。

最终的顺序是抵达日逛大栅栏，之后依次去故宫、八达岭长城、798艺术区和北京动物园，第六天返程。故宫放在周五，798看展放在周日，周一留给动物园，避开部分场馆的闭馆日。住宿和餐饮也围绕这个顺序收拢，不再只是几张互不相连的候选名单。

住宿也在这个阶段收束为一个选择：全程住在王府井或东单片区，五晚不换酒店，去较远的景点当天往返。如果每天搬到下一个景点附近，可能少花一些通勤时间，却也增加收拾和搬运行李的次数。最终方案保留了固定落脚点，接受部分行程的通勤距离。

确定安排后，「豆包工作」生成了一份 20 页PPT。它从六天总览开始，按天展开，再放入行前准备、交通、预算、美食和住宿建议。原先分散在网页、表格和几份文档中的材料，进入了一份同行者可以一起看的文件。

预算页给出的两人估算约为6310元，不含往返北京的大交通，并把住宿、餐饮、门票和交通等分开列出。同行者想住得更好，可以先调整住宿这一项；想少走一点路，可以指向具体某一天修改。讨论不必再从一大段聊天记录里寻找对应信息。

不过仍是一份需要调整的内容呢。行程天数变化后，早期资料中的日期需要同步，酒店价格与预约信息要按实际出行时间确认。已有的候选表、详细资料和可编辑文件，都可以继续用于下一轮修改。

个人 Agent 开始接住一整段任务

旅行只是一个容易理解的场景。找工作需要收集岗位、比较要求，再准备申请材料；做行业研究，需要追踪信息、筛选公司，最后形成报告。这些事情都跨越多个网页和工具，前一步得到的结果，还要继续用于下一步工作。

这次体验中，「豆包工作」已经展示了其中一部分能力：用户示范过的查询方法可以保存，几组资料可以并行收集，结果能够继续进入表格和PPT。人负责提出条件、做出取舍，Agent承担一部分原本需要反复打开页面、摘录和整理的工作。

随着这些环节逐渐连贯，用户对AI的要求也可能发生变化。从“帮我查一条信息”，到“按我的要求把这件事推进下去”，新的需求会给更具体的个人Agent留下空间。围绕求职、采购或学习形成的产品，需要熟悉各自的信息来源、筛选标准和交付要求，才能进一步接手工作。

对豆包工作而言，接下来的问题是怎样让这段过程更短、更稳定。当用户不必反复交代背景，也不必在每个环节接手搬运资料，一次示范、几次必要的判断，就有机会推动一项完整任务。「豆包工作」要继续做的，是把这样的过程带到更多日常需求里。