Jobber AI投简历Agent双架构深度对比多Agent对话 vs 有限状态机谁更可靠【免费下载链接】jobberbrowser controlling AI agent that applies to relavant jobs on internet autonomously. join chat https://discord.gg/umgnyQU2K8项目地址: https://gitcode.com/gh_mirrors/jobber4/jobberJobber 是一个控制浏览器的 AI Agent能替你在互联网上自主搜索并投递相关职位——你只需要提供简历和求职偏好它就在工作网站后台帮你完成投递。这个开源仓库里最有趣的地方在于同一件事作者用两种截然不同的架构实现了两遍分别放在jobber/和jobber_fsm/两个目录中。jobber多 Agent 对话架构Planner 规划者 Browser Agent 浏览器导航员靠聊天协作jobber_fsm有限状态机架构状态在 PLAN → BROWSE → COMPLETED 之间流转官方说明两者性能水平相近但 FSM 方案更具扩展性。那它们到底差在哪该选哪个这篇文章带你一次看懂。两个版本的架构差异一览维度jobber多 Agent 对话jobber_fsm有限状态机核心机制Planner 与 Browser Agent 互相发送文字消息循环协作显式状态机驱动状态切换路径固定通信格式自由文本 约定标记如##TERMINATE TASK##Pydantic 结构化输入/输出模型字段强约束记忆管理隐式保存在对话历史中显式Memory模型计划、已完成任务、当前任务等模型要求任意大模型默认 gpt-4o-mini也兼容开源模型依赖 OpenAI 结构化输出能力固定 gpt-4o控制台体验普通文本输出彩色面板展示当前状态、计划与任务进度扩展性简单直接适合学习官方认定的持续演进方向多Agent对话架构两个AI靠聊天投简历jobber版本的思想很朴素把任务交给一个Planner规划者它拆解目标并给BrowserNavAgent浏览器导航员下达自然语言指令导航员操作完浏览器后把结果汇报回来Planner 再决定下一步如此往复直到任务结束。关键实现都在这些文件里jobber/core/system_orchestrator.py总入口接收用户指令并驱动整个对话循环jobber/core/agents/planner_agent.py规划者持有对话主循环while True负责判断该让浏览器动手了还是任务结束jobber/core/agents/base.pyAgent 基类通过 litellm 调用 LLM 并解析回复它的对话终止靠的是约定俗成的文本标记模型输出中出现##TERMINATE TASK##或可解析的 JSONterminate: yes才认为任务完成。灵活是灵活但这种靠读文字的解析方式天然比结构化格式多一层不确定性。它的最大优势不绑定任何模型厂商。基类中模型配置默认为gpt-4o-mini你也可以换成更便宜甚至开源的模型来跑——对预算有限的用户非常友好。有限状态机架构状态流转让协作有章法jobber_fsm版本把 Agent 协作抽象成一台有限状态机FSM这是它在可靠性上的核心升级状态只有三种PLAN规划、BROWSE执行浏览、COMPLETED完成定义在jobber_fsm/core/models/models.py每个状态绑定一个 Agent{PLAN: PlannerAgent, BROWSE: BrowserNavAgent}在jobber_fsm/__main__.py中一行代码完成映射主循环while self.memory.current_state ! State.COMPLETED持续推进状态流转逻辑见jobber_fsm/core/orchestrator/orchestrator.py更关键的是结构化输出Planner 的每次产出必须严格符合PlannerOutput包含plan、next_task、is_complete等字段Browser Agent 则返回BrowserNavOutput。jobber_fsm/core/agent/base.py中通过 OpenAI 的 structured outputsresponse_formatself.output_format保证模型只能输出合法 schema 的 JSON——不是希望它输出 JSON而是强制它输出 JSON。此外全局的Memory模型把目标、当前状态、计划、已完成任务、最终回答全部显式记录控制台还会用彩色面板实时展示计划清单和勾选进度调试体验明显更好。它的代价因为依赖 OpenAI 的结构化输出能力模型被固定为gpt-4o-2024-08-06不能换成 gpt-4o-mini 或开源模型。可靠性对比结构化输出 vs 文本标记谁更稳把两种方案放在一起看结论其实很清晰输出可靠性 → FSM 胜出 对话架构靠正则/JSON 抽取解析自由文本模型话痨或格式漂移时可能解析失败代码里也专门捕获了这类异常状态机架构用强 schema 兜底字段缺失或类型错误会直接报错问题暴露得更早、更明确。记忆可靠性 → FSM 胜出Memory模型让已完成什么、还剩什么有唯一事实来源对话架构则依赖不断增长的上下文窗口长任务中信息可能被淹没。模型灵活性 → 对话架构胜出想省钱或想用本地开源模型只有jobber版本行得通。扩展性 → FSM 胜出新增一种状态比如等待用户确认只需注册新的 State 和对应 Agent不需要改动对话解析逻辑这也是官方将 FSM 定为持续演进方向的原因。快速上手两步运行两个版本两个版本共享同一套技能库点击、输入文本、截图、上传简历等位于jobber/core/skills/与jobber_fsm/core/skills/上手步骤一致克隆仓库并安装依赖git clone https://gitcode.com/gh_mirrors/jobber4/jobber cd jobber poetry install以调试模式启动 Chrome 并登录求职网站LinkedIn、Wellfound 等配置.env密钥在user_preferences/user_preferences.txt中填写求职偏好与简历本地路径选择架构二选一运行python -u -m jobber # 多Agent对话版 python -u -m jobber_fsm # 有限状态机版输入任务即可官方示例apply for a backend engineer role based in helsinki on linkedin如果想量化对比两者表现仓库提供了基于 WebVoyager 任务的评测入口test/tests_processor.py支持--orchestrator_type vanilla / fsm分别跑分。选型建议你该用哪个版本想学习多 Agent 协作的最小实现读jobber代码直白对话循环一目了然想控制成本或用开源模型只能选jobber要在真实工作流中长期稳定运行、或继续扩展功能选jobber_fsm状态机 结构化输出的组合是更可靠的工程化底座 ⚖️一句话总结对话架构胜在灵活状态机架构胜在可靠。性能上二者旗鼓相当而可靠且可扩展正是自动化 Agent 真正落地时最稀缺的品质——这也解释了为什么作者把未来的改进重心放在了jobber_fsm上。【免费下载链接】jobberbrowser controlling AI agent that applies to relavant jobs on internet autonomously. join chat https://discord.gg/umgnyQU2K8项目地址: https://gitcode.com/gh_mirrors/jobber4/jobber创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考