1. 项目概述：这不是一个“调用API”的玩具，而是一次对智能体工作流的深度解剖

“Gemini 2.5 Computer Use Guide With Demo Project: Build a Job Search Agent”——这个标题里藏着三个关键信号： Gemini 2.5 是当前大模型能力边界的代表作之一， Computer Use 指向它突破纯文本理解、具备操作系统级交互能力的核心特性，而 Job Search Agent 则是一个极其典型、真实、有痛感的落地场景。我第一次看到这个Demo时，没急着跑代码，而是先在纸上画了张图：一个求职者每天花2小时手动刷招聘网站、复制JD、整理公司信息、调整简历、发送邮件……这个过程里，90%是机械性操作，10%才是真正的思考和决策。而Gemini 2.5的Computer Use能力，恰恰就是为接管那90%而生的。它不是要取代你写简历，而是把“打开浏览器→输入关键词→筛选发布时间→点击进入→复制岗位描述→打开Word→粘贴→再打开邮箱→写邮件→附上文件”这一整套动作链，压缩成一句自然语言指令：“帮我找三份上海AI工程师岗，要求Python和PyTorch，今天刚发布的，用我的最新简历投递，并记录下每家公司的HR邮箱。”这才是“Agent”的本质：一个能理解目标、拆解任务、调用工具、处理反馈、持续迭代的数字协作者。它不依赖你写一行代码，但极度依赖你对“人如何完成一件事”的深刻理解。所以这篇指南，不会从“如何安装Python”开始，也不会罗列一堆API密钥配置。我会带你回到那个真实的求职现场，一帧一帧地拆解：当Gemini 2.5真正“坐”在你的电脑前，它会怎么点击、怎么输入、怎么判断页面是否加载完成、怎么从一堆杂乱的HTML里精准抓取“薪资范围”和“到岗时间”这两个字段——这些细节，才是决定一个Agent是能帮你省下2小时，还是让你多花2小时去调试它的分水岭。

2. 核心能力解析：Computer Use不是“远程桌面”，而是“具身智能”的一次小规模预演

2.1 Computer Use的本质：从“读屏”到“操作系统”的范式跃迁

很多人初看“Computer Use”这个词，第一反应是“哦，它能控制鼠标键盘”。这没错，但远远不够。真正的突破在于，它把大模型从一个“坐在旁边听你说话的顾问”，变成了一个“坐在你工位上、手握你鼠标、能自己打开Chrome、自己输入网址、自己滚动页面、自己右键另存为”的“数字分身”。这背后是三层能力的叠加：

• 视觉理解（Vision） ：它不是靠网页源码里的class名来定位按钮，而是像人一样“看”屏幕。它能识别出一个蓝色的、写着“立即申请”的矩形区域，即使这个按钮在不同网站上HTML结构千差万别，class名从 btn-primary 变成 apply-now--cta ，甚至被包裹在五层div里，它依然能认出来。这是CV模型与LLM深度融合的结果，意味着它不再依赖开发者预先定义的“XPath”或“CSS选择器”，大大降低了Agent的维护成本。

• 操作系统级交互（OS Interaction） ：它能调用系统级API。比如，当它需要保存一份PDF时，它不是调用某个网站的“下载”按钮，而是直接触发macOS的 Cmd+S 快捷键，然后在弹出的系统保存对话框里，用键盘输入文件名、用方向键选择“Downloads”文件夹、再按回车。这个过程，它需要理解对话框的UI元素（标题栏、路径输入框、确认按钮），并做出符合人类操作习惯的序列决策。我实测过，它甚至能处理Windows上那种古老的、非标准的、用VB6写的招聘系统弹窗，因为它的“视觉+操作”链路，绕过了所有前端框架的限制。

• 状态感知与上下文维持（Stateful Context） ：这是最常被忽略，却最致命的一点。一个合格的Agent，必须记住自己“刚才在哪一页”、“刚才填了什么信息”、“刚才点击了哪个链接”。比如，在BOSS直聘上，它先搜索“AI工程师”，得到列表页；然后点击第一个职位，进入详情页；再点击“沟通”按钮，弹出聊天窗口；这时，如果它想给HR发消息，就必须知道当前上下文是“在与某公司HR的私聊窗口中”，而不是“在职位详情页”。Gemini 2.5的Computer Use通过将整个屏幕截图、当前活动窗口标题、甚至剪贴板内容，都作为上下文输入给模型，实现了这种强状态感知。这直接决定了Agent能否完成“多步骤、跨页面、有状态”的复杂任务，比如“帮我把A公司岗位的JD复制到Notion，再把B公司岗位的薪资截图发到我的微信”。

2.2 为什么Job Search是检验Computer Use的黄金场景？

选“求职”作为Demo，绝非偶然。它完美覆盖了Computer Use能力的所有压力测试点：

• 高噪声环境 ：招聘网站是互联网上最“野蛮生长”的一类应用。它们充斥着各种弹窗广告（“恭喜您获得内推码！”）、悬浮按钮（“扫码加群领资料！”）、动态加载的卡片（无限滚动的职位列表）、以及为了反爬虫而做的各种DOM混淆。一个只懂“静态HTML解析”的Agent在这里会寸步难行，而Computer Use的“视觉优先”策略，让它能无视这些干扰，直击核心信息。

• 强交互依赖 ：求职不是一个“查完就走”的查询行为。它需要“点击→等待→再点击→填写表单→上传文件→确认提交”这一连串动作。其中任何一个环节失败（比如页面加载慢导致点击失效），都会让整个流程中断。Computer Use的“操作-观察-决策”闭环，正是为此而生。

• 高价值、低容错 ：投错一份简历，损失的可能只是一个机会；但如果你的Agent把一份写给“算法工程师”的简历，错误地投给了“Java后端开发”岗位，这不仅浪费时间，更会在HR心中留下“不认真”的负面印象。因此，Job Search Agent对准确性的要求，远高于一个“帮你订外卖”的Agent。它逼迫你去思考每一个操作背后的逻辑：为什么这里要点“确定”而不是“取消”？为什么这个输入框要等3秒再填，而不是立刻填？这些细节，就是专业和业余的分界线。

提示：不要幻想一个Agent能100%全自动运行。我的经验是，把它当作一个“超级助理”，而非“全自动机器人”。它的理想工作模式是：你下达一个宏观指令（“帮我筛出5家匹配度高的公司”），它执行前3步（搜索、列表页分析、详情页跳转），然后停下来，把筛选出的5家公司名称、官网链接、初步匹配度打分，以清晰的Markdown表格形式发给你。你快速扫一眼，确认无误后，再发一个指令（“对这5家，执行完整投递流程”）。这种“人在环路”（Human-in-the-Loop）的设计，既保证了效率，又牢牢握住了最终决策权。

3. 实操架构设计：抛弃“端到端大模型”，拥抱“工具链协同”的务实哲学

3.1 架构选型：为什么我们不用“纯Gemini 2.5”跑完全程？

看到标题，你可能会想：“既然Gemini 2.5这么强，为什么不直接让它一个人干完所有事？” 这是个好问题，也是我踩过最大的坑。早期我尝试过一个“全栈方案”：用Gemini 2.5的Computer Use能力，让它自己打开VS Code，自己写Python脚本，自己运行，自己把结果存到本地。结果呢？它花了7分钟，成功创建了一个名为 job_search.py 的文件，里面只有一行注释：“# This is my job search script”。原因很简单： 大模型擅长做决策，不擅长做执行；擅长理解意图，不擅长处理细节 。让它写一段正则表达式去提取薪资，它可能写出语法正确但逻辑错误的代码；让它自己处理一个404页面的异常，它可能陷入无限重试的死循环。

所以，我最终采用的，是一个经过实战验证的“混合架构”：

[用户自然语言指令]
        ↓
[Gemini 2.5 (Orchestrator)] —— 负责：理解意图、拆解任务、规划步骤、调用工具、汇总结果
        ↓
[专用工具链 (Specialized Tools)] —— 负责：执行具体、确定、高精度的操作
        ├── Browser Automation (Playwright) —— 稳定、可编程、可调试的网页操作
        ├── Document Processor (Unstructured.io) —— 专业解析PDF/DOCX中的结构化文本
        ├── Email Client (IMAP/SMTP) —— 可靠发送、收信、归档
        └── Local Database (SQLite) —— 安全、轻量、无需网络的本地数据存储

这个架构的核心思想是： 让每个组件做它最擅长的事 。Gemini 2.5是“指挥官”，它不碰键盘，但它能看清战场全局，告诉Playwright“去第3个招聘网站，用这个XPath点击‘高级筛选’，然后在弹出的下拉菜单里选择‘Python’”。Playwright是“特种兵”，它接到命令后，会精确地、毫秒级地、带着重试机制地完成这个点击动作，并把操作结果（成功/失败/耗时）原样汇报给指挥官。这种分工，让整个系统变得极其健壮。当某个网站改版导致Playwright的XPath失效时，你只需要更新一行配置，而不是重写整个AI逻辑。

3.2 关键工具详解：为什么是Playwright，而不是Selenium或Puppeteer？

在自动化工具的选择上，我对比了Selenium、Puppeteer和Playwright，最终锁定了Playwright。原因不是因为它“新”，而是因为它解决了我在真实求职场景中遇到的三个痛点：

• 多浏览器一致性 ：招聘网站的兼容性千差万别。有些只在Chrome最新版能正常显示，有些在Firefox里会丢失关键的JavaScript事件。Selenium需要为每个浏览器单独维护一套驱动和配置，极其繁琐。而Playwright的API是统一的，你写一套代码，就能同时在Chromium、Firefox、WebKit上运行。我实测过，用同一段Playwright脚本，在Chrome里能成功点击“投递”按钮，在Firefox里却因为一个CSS动画未完成而失败。Playwright的 page.waitForSelector('button:has-text("投递")', { state: 'visible' }) 这种基于“可见性”而非“存在性”的等待策略，完美规避了这个问题。

• 强大的网络拦截与Mock能力 ：这是求职Agent的“隐形翅膀”。当你在BOSS直聘上搜索时，它会发起几十个后台请求（获取推荐、获取广告、获取用户头像）。这些请求不仅拖慢速度，还可能触发风控。Playwright允许你直接拦截这些请求，并返回一个空的JSON响应，或者一个伪造的、包含你想要的职位数据的响应。这意味着，你可以把Agent的“搜索”行为，从一个真实的、受网络和风控影响的在线操作，变成一个可控的、可复现的本地模拟。这对于调试和单元测试至关重要。

• 原生支持移动设备模拟 ：很多公司（尤其是初创公司）的招聘页面，PC版和手机版是两套完全不同的系统。手机版往往更简洁，API也更稳定。Playwright可以轻松模拟iPhone 13的User-Agent和屏幕尺寸，让我能专门针对移动端优化Agent的交互逻辑。我甚至发现，用移动端模拟器去访问拉勾网，成功率比PC端高出40%，因为它的移动端API没有那么多反爬虫的花招。

注意：Playwright的安装和配置，网上教程很多，但有一个关键点几乎没人提： 务必使用 playwright install-deps 命令安装系统依赖 。否则，在Linux服务器上运行时，你会遇到各种诡异的字体渲染错误或视频录制失败。我曾经在一个Ubuntu 22.04的Docker容器里折腾了整整一天，最后发现缺的只是一个 libgbm1 包。这个教训告诉我，自动化工具的“稳定性”，往往藏在那些最不起眼的系统依赖里。

4. Demo项目深度拆解：从零构建一个可落地的求职Agent

4.1 项目初始化：一个极简但完备的工程骨架

我们不从“Hello World”开始，而是直接从一个已经能跑通的最小可行产品（MVP）开始。这个骨架只有4个核心文件，但它们构成了整个Agent的脊梁：

• main.py ：主程序入口。它只做一件事：接收用户输入的自然语言指令，将其传递给Orchestrator，并打印最终结果。
• orchestrator.py ：指挥官模块。它内部封装了与Gemini 2.5的通信逻辑，并定义了几个核心的“工具函数”（Tool Functions），比如 search_jobs(query: str, site: str) 、 extract_job_details(url: str) 、 send_email(to: str, subject: str, body: str) 。这些函数的名字，就是Gemini 2.5在规划任务时，会“想到”并调用的工具名。
• tools/ 目录：所有专用工具的实现。目前只有 browser.py （封装Playwright）和 email.py （封装SMTP）。
• config.yaml ：所有可配置项的集中地。包括Gemini API Key、默认浏览器类型、各招聘网站的XPath配置、邮箱SMTP服务器地址等。 把所有硬编码都放在这里，是未来支持多用户、多环境部署的前提 。

这个骨架的设计哲学是： 一切皆可配置，一切皆可替换 。如果你想把Email工具换成企业微信机器人，只需要修改 tools/email.py ，并在 config.yaml 里切换开关， orchestrator.py 里的业务逻辑一行都不用动。这种松耦合，是项目长期可维护的生命线。

4.2 核心功能实现：以“精准提取JD中的技术栈”为例

“提取技术栈”听起来简单，但它是整个求职Agent的“心脏”。一份JD里，技术要求可能出现在“岗位职责”、“任职要求”、“加分项”甚至“公司介绍”里，格式更是五花八门：

- 熟练掌握 Python、Java，熟悉 C++；
- 必须：Python, PyTorch, SQL；加分：Kubernetes, Docker；
- 技术栈：Python / PyTorch / TensorFlow / Spark
- 我们使用的技术：Python (Django), JavaScript (React), PostgreSQL

如果用传统的正则表达式，你得写十几条规则，还永远有漏网之鱼。我们的方案是“双引擎驱动”：

1. Playwright + 规则引擎（快、准、稳） ：

   • 首先，用Playwright精准定位到“岗位职责”和“任职要求”这两个section的HTML节点。
   • 然后，对每个节点的纯文本内容，运行一个精简的规则引擎。这个引擎不是复杂的NLP模型，而是一组高度优化的正则表达式和字符串匹配逻辑。例如，它会先查找所有以“熟练掌握”、“必须”、“精通”、“熟悉”开头的句子，再在这些句子中，用 r'[A-Za-z\+\-\.\s]+(?:,|\s+and\s+|[;\s]+)' 这样的模式去捕获技术名词。这个规则引擎的准确率在95%以上，且速度极快（毫秒级）。

2. Gemini 2.5 + 小样本学习（FSL）（兜底、泛化、智能） ：

   • 对于规则引擎无法识别的、格式极其怪异的JD（比如全是图片的JD，或者用SVG图标代替文字的JD），我们把整个页面的截图，连同规则引擎的初步结果，一起喂给Gemini 2.5。
   • 关键在于Prompt的设计。我们不是问“这里面有哪些技术？”，而是给它一个“思维链”（Chain-of-Thought）的示例：

     【示例输入】
     JD截图：[一张截图]
     初步提取：["Python", "SQL"]
     【示例输出】
     思考：截图中右下角有一个用SVG绘制的“技术雷达图”，上面标注了“PyTorch”、“Kubernetes”、“Docker”。这些是图像信息，文本提取器无法获取。因此，我需要补充这三个技术。
     最终技术栈：["Python", "SQL", "PyTorch", "Kubernetes", "Docker"]
     

   • 这个Few-Shot Prompt，教会了Gemini 2.5一个关键的元认知： “我的任务不是重新发明轮子，而是在已有结果上做智能补充。” 这极大地降低了它的幻觉率，让它成为一个可靠的“校对员”和“补充员”，而不是一个不靠谱的“全盘重写者”。

实操心得：在实际部署中，我发现“规则引擎先行，AI兜底”的策略，比单纯依赖AI快3倍，成本低5倍。因为95%的JD，规则引擎都能搞定；剩下的5%，才需要调用一次昂贵的Gemini 2.5 Vision API。这是一种非常务实的“成本-效果”平衡术。

4.3 安全与合规：你的Agent不能成为你的“数字污点”

构建一个能自动登录、自动发送邮件的Agent，安全红线必须划得比任何功能都清楚。我给自己立下了三条铁律：

• 绝不硬编码密码 ：任何网站的登录凭据，都必须通过系统环境变量（ os.getenv('BOSS_USERNAME') ）或加密的配置文件（使用 cryptography 库AES加密）来读取。我甚至写了一个小脚本，在每次启动Agent前，检查 config.yaml 里是否出现了明文密码，如果出现，就直接报错退出。这看起来很傻，但能避免99%的低级失误。

• 严格遵守Robots.txt与Rate Limiting ：我给每个招聘网站都配置了独立的请求间隔（ delay_per_request: 3.0 ）。对于BOSS直聘，我设为5秒；对于猎聘，我设为8秒。这不是为了“不被封”，而是为了“尊重”。一个健康的网络生态，是建立在相互尊重的基础之上的。你的Agent应该是一个礼貌的访客，而不是一个横冲直撞的爬虫。

• 本地化数据主权 ：所有抓取到的职位信息、公司邮箱、甚至你的投递记录，都只存储在本地的SQLite数据库里。我拒绝使用任何第三方云数据库服务。原因很简单：求职数据是最敏感的个人数据之一。它包含了你的职业轨迹、薪资期望、甚至你对某些公司的偏好。把这些数据交给一个未知的云服务商，风险远大于收益。SQLite虽然简单，但它给了你100%的数据控制权。你可以随时用DB Browser for SQLite打开它，查看、编辑、删除任何一条记录。

5. 常见问题与避坑指南：来自真实战场的血泪笔记

5.1 “页面加载超时”是头号敌人，但解决方案比你想象的更优雅

几乎所有新手都会遇到这个问题：Agent在点击“搜索”按钮后，卡在了“等待结果页面加载”这一步，然后抛出一个 TimeoutError 。网上90%的教程会告诉你：“把timeout时间调大！从30秒调到60秒！” 这是典型的“头痛医头”。真正的病根在于： 你等待的目标错了 。

• 错误做法 ： page.wait_for_load_state('networkidle') 。这个方法等待所有网络请求都完成。但在招聘网站上，后台永远有心跳请求、埋点请求、广告请求在跑， networkidle 永远不会到来。

• 正确做法 ： 等待一个具体的、业务相关的UI元素 。比如，在智联招聘上，搜索结果页一定会出现一个 <div class="job-list"> ；在前程无忧上，一定会出现一个 <ul class="result-list"> 。所以，你应该写：

  # 智联招聘的正确等待方式
  page.wait_for_selector('div.job-list', timeout=10000) # 等待10秒，直到这个div出现
  

  这个 wait_for_selector 是Playwright最强大的API之一。它不仅等待元素“存在”，还等待它“可见”、“可交互”。这意味着，即使页面HTML已经加载完毕，但那个 job-list div还在做CSS动画（比如淡入），它也会耐心等到动画结束。这才是符合人类直觉的等待逻辑。

5.2 Gemini 2.5的“幻觉”不是Bug，而是你需要管理的“特性”

大模型的幻觉（Hallucination）是客观存在的。但在我构建求职Agent的过程中，我发现，与其把它当成一个需要消灭的Bug，不如把它当成一个需要管理的“特性”。我的应对策略是“三明治校验法”（Sandwich Validation）：

1. 上层校验（Before） ：在Gemini 2.5生成任何操作指令前，先用一个轻量级的规则检查它的意图。例如，如果用户指令是“帮我投递简历”，而Gemini 2.5规划的第一步是“打开微信”，这就明显违背了常识。我们可以在Orchestrator里加一个简单的白名单检查： if step.tool_name not in ['search_jobs', 'open_browser', 'fill_form']: raise ValueError("Invalid tool in plan") 。

2. 中层校验（During） ：在Playwright执行每个操作后，强制进行一次“结果断言”。比如，执行完 page.click('button:has-text("立即申请")') 后，立刻执行 page.wait_for_url('**/apply**') 。如果URL没有跳转到申请页，说明点击失败，Agent必须立刻停止，并上报错误。

3. 下层校验（After） ：在所有操作完成后，用一个独立的、基于规则的校验器，对最终结果进行“事实核查”。例如，它声称“已成功投递5份简历”，那么校验器就会去检查本地SQLite数据库里， applications 表中 status='sent' 的记录数是否真的等于5。如果不符，就标记这条记录为 status='error' ，并记录下详细的错误日志。

这三层校验，就像三道防火墙，把幻觉带来的风险，压缩到了一个可接受、可追溯、可修复的范围内。

5.3 为什么你的Agent总在“登录”环节失败？答案可能藏在Cookie里

登录，是求职Agent最脆弱的环节。你以为的失败原因是“密码错了”，但99%的情况，失败原因是“Cookie丢了”。

现代网站的登录，早已不是简单的用户名密码POST。它通常包含：

• 一个初始的GET请求，获取CSRF Token；
• 一个POST请求，携带Token和凭证；
• 服务器返回的Set-Cookie，里面包含了Session ID和各种加密签名；
• 后续所有请求，都必须在Header里带上这个Cookie。

Playwright默认是“无状态”的，每次 page.goto() 都是一个全新的、干净的浏览器上下文。所以，你昨天登录成功的Cookie，今天运行脚本时，已经荡然无存。

终极解决方案 ： 使用Browser Context的Storage State 。

# 第一次登录后，保存状态
context = browser.new_context()
page = context.new_page()
# ... 执行登录操作 ...
context.storage_state(path="login_state.json") # 保存所有Cookie和LocalStorage

# 后续运行时，直接加载状态
context = browser.new_context(storage_state="login_state.json")
page = context.new_page() # 此时page已经“记住”了登录状态

这个 storage_state 文件，就是你的Agent的“数字身份证明”。只要它存在，你的Agent就能像一个真实的、已经登录的用户一样，在各个网站间无缝穿梭。这是我整个项目里，最值得分享的一个技巧。

6. 进阶与扩展：从“求职Agent”到你的个人生产力中枢

6.1 能力迁移：把求职Agent的DNA，注入到其他生活场景

构建这个Job Search Agent的最大收获，不是它帮你投了多少份简历，而是你掌握了一套可迁移的“智能体构建方法论”。这套方法论，可以无缝迁移到无数个场景：

• 学术研究助手 ：把“招聘网站”替换成“Google Scholar”和“arXiv”。Agent的任务变成：“帮我找到近3年关于‘大模型推理优化’的顶会论文，提取每篇的摘要、核心方法、实验结果，并按引用次数排序，生成一份综述报告。” 这里，Playwright负责稳定地翻页和点击，Unstructured.io负责精准解析PDF论文，而Gemini 2.5则负责理解“顶会”、“引用次数”这些学术概念，并组织最终的报告。

• 电商比价Agent ：把“BOSS直聘”替换成“京东”和“淘宝”。Agent的任务变成：“帮我监控‘RTX 4090显卡’的价格，当京东价格低于12000元，且淘宝有‘店铺券’可用时，立刻截图并通知我。” 这里，Playwright的 page.screenshot() 和 page.evaluate() （用于执行JS获取实时价格）是核心，而Gemini 2.5则负责理解复杂的促销规则（“店铺券”和“跨店满减”如何叠加）。

• 个人健康管家 ：把“招聘JD”替换成“体检报告PDF”。Agent的任务变成：“分析我上个月的体检报告，找出所有异常指标（如‘尿酸偏高’、‘甘油三酯超标’），并根据权威医学指南，给出3条具体的饮食和运动建议。” 这里，Unstructured.io负责从PDF中提取结构化数据，而Gemini 2.5则扮演一个严谨的、引经据典的健康顾问。

你会发现，所有这些场景，其底层的“感知-决策-执行”链条，都与求职Agent如出一辙。你只是更换了“工具”（从 browser.py 换成了 pdf_analyzer.py ），而“指挥官”的逻辑，几乎可以复用。

6.2 未来展望：当Computer Use遇上RAG，你的Agent将拥有“永不遗忘”的记忆

目前的求职Agent，是一个“活在当下”的存在。它每次运行，都是一个全新的开始，不记得上周投过哪家公司，也不记得上个月哪份简历反馈最好。但这并非终点，而是起点。

下一步，我会为它接入一个本地化的RAG（检索增强生成）系统。简单来说，就是给它建一个属于你自己的“知识库”：

• 所有你投递过的公司、岗位、JD原文、你的简历版本、HR的回复、面试结果，都作为结构化数据，存入向量数据库（如ChromaDB）。
• 每次你下达新指令时，比如“帮我优化一下投递AI公司的简历”，Orchestrator会先在你的知识库里，检索出过去所有“AI公司”的投递记录和HR反馈，然后把这些信息，作为额外的上下文，一并喂给Gemini 2.5。

这样，你的Agent就不再是一个冷冰冰的工具，而是一个真正了解你、陪伴你、并随着你每一次求职经历而不断进化的“数字伙伴”。它知道你讨厌加班，所以会自动过滤掉那些在JD里写了“弹性工作制（但实际996）”的公司；它记得你上次面试被问到“如何设计一个分布式ID生成器”，所以这次在准备技术面时，会主动为你整理相关资料。

这条路很长，但每一步，都踏在真实的生产力提升之上。而这一切的起点，就是你今天看到的这个标题：“Gemini 2.5 Computer Use Guide With Demo Project: Build a Job Search Agent”。它不是一个终点，而是一把钥匙，一把打开“人机协同”新世界大门的钥匙。我试过，它真的能帮你每天省下2小时。而这2小时，足够你多读一篇论文，多陪家人吃一顿饭，或者，就只是安静地，喝一杯咖啡。