最近看到很多找工作的伙伴在用AI写简历 injob Ai，突然期望能不能做一个AI来帮助用户自动写简历的东西。为此观察了大家使用Ai的习惯，逐步探索出一条适合的多Agent协同的写简历的方案逻辑，简单说下三者有什么不同。
想必很多人第一次用 AI 写简历，都是打开一个对话框，输入一句话：“帮我写份××岗位的简历 + 一对内容”
- 结果呢？模型生成一堆看起来“得漂亮”，但往往内容不够专业、不够稳定，内容能用又不能用的尴尬情况。
- 为什么昵？这是因为它还只是一个“更会说话的模型”，而不是一套有组织、有流程的简历生产体系。
为此我们做的尝试，是把写简历这件事，从“对话”提升到“工作化的流程上”。为此参考 Manus 的三元 Agent 架构（规划 → 执行 → 验证），我们设计了三元协同写简历模式（对话 → 计划 → 执行）。
它不只是会写，而是像一条专业的“简历流水线”，让结果更可控、更稳定、更贴合岗位。
纯模型对话和单Agent写简历有什么问题，三元结构的多Agent有什么优势？
阶段1：纯模型对话（Pure LLM Chat）
就像和一个充满智慧的人闲聊，但问题也最多：
- 稳定性差：一次说得准，下次就跑偏，上下文一长，约束就被遗忘。被打岔，可用性低
- 易幻觉：无中生有，自行大面积扩散，说的都对，但是可用又不可用。
- 结构不可控：自由发散，可能记忆混乱、要点缺失、不停的补充、上下内容不一致、已丢失。
- 对用户要求高：需要用户自己懂岗位、懂关键词、懂怎么喂提示词。
结果：适合给你提供灵感草稿，不适合直接做事情，思考依赖人。效果如图
阶段2：单Agent（Single Agent Pipeline）
有了流程意识，但还是“一人身兼数职”，agent匹配不堪：
有了改进：会按模板生成、会参考JD、会抽取关键词、能做有限校对。
局限性也很明显：
- 角色混淆：同一个Agent既采集需求又写作又校验，容易自我干扰、自相矛盾。
- 长上下文漂移：流程越长越容易忘前面定下的规则。
- 纠错成本高：一处错误常导致“整份重来”，上下文太多混乱，不可局部重试。
- 可观测性弱：哪一步出了问题不易定位，难以持续优化。
结果：能产出“像模板”的简历，但在复杂岗位/多段经历时，质量与稳定性仍不够。修改成本高
阶段3：三元协同多Agent（Dialogue → Plan → Execute ）
分工明确，流水线产出、结构稳定：
- 对话Agent（收集需求）：像产品经理，问清岗位、经历、成果、量化指标，补齐变量。
- 计划Agent（制定蓝图）：像项目经理，拆解结构、选择模板、明确每段经历的“能力锚点”与关键词。
- 执行Agents（模块写作）：像执行团队、开发测试。执行对应的内容，不用共享记忆，相互独立，互不干扰，可分别重试。
结果：稳定、可控、可追踪、分模块接受信息，避免自我干扰。操作简单，你只需提问题，即可执行任务。
演化路径与能力对比如下
可以看到，越往后越稳定，对使用者的要求越低，效果越好。
injob AI：三元骨架：对话 → 计划 → 执行流程梳理
对话 Agent：把“经历”采成“变量”
像产品经理采需求，围绕 JD 维度提问，抽取并标准化：
- 岗位/行业/级别、必备能力关键词
- 关键经历（职责、动作、方法、结果、影响）
- 可量化指标（增⻓%、节省成本、效率倍数、覆盖人群）
计划 Agent：把“变量”排成“蓝图”：
像项目经理制定方案：
- 选择合适的简历结构与模板（应届/社招/技术/产品/运营等）
- 提取岗位关键词并分配到对应模块
- 生成主要简历
执行 Agents：把“蓝图”写成“成品”
- 多路并行：教育/经历/项目/技能/补充模块独立生成
- 抗干扰：各模块上下文隔离，不会互相“带跑偏”
效果
更稳定、也更“省心”，使用成本更低
- 分层解耦：对话只采集、计划只规划、执行只写作，职责清晰，减少“自我干扰”。
- 对使用者更友好：你只要说人话（目标与经历），其余交给系统问、系统定、系统写。
实际体验上的差异
- 纯对话：你得懂怎么跟模型说话，结果看缘分。
- 单Agent：像填表，但遇到复杂经历容易“失真”。
- 三元协同：像被专业顾问带着走——问到位、写到点、改到好。
本文由 @易俊源 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
