最近看到很多找工作的伙伴在用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：像填表，但遇到复杂经历容易“失真”。
• 三元协同：像被专业顾问带着走——问到位、写到点、改到好。