企业官网建设流程全解析

1. 为什么简历生成不能靠"一次大模型调用"搞定

先说个我踩过的坑。最早我天真地以为，写简历这玩意儿不就是把用户的经历丢给大模型，让它润色成几段漂亮的描述吗？结果第一个demo就跑出了严重问题：用户丢进来一句"我在某公司做了三年运营，负责用户增长"，模型直接给出一段"主导用户增长策略，通过多渠道优化实现GMV显著提升"的漂亮话，看着唬人，但简历里所有数据全是编的，连用户没提过的"多渠道"都给脑补出来了。投出去被面试官一问就露馅，这简历谁敢收？

你仔细想就会发现，简历生成的难点根本不在"写句子"，在于信息完整性校验、岗位匹配分析、经历量化重构、排版合规、以及多轮追问。这些任务互相依赖，但又各有一套逻辑：

• 岗位匹配要求解析JD里的关键词，这是信息抽取任务；
• 经历量化要求理解用户原始描述中隐含的成果，这是推理任务；
• 信息补全要求针对缺失的关键要素（比如数据、时间范围）主动向用户提问，这是对话管理任务；
• 最后合稿还需要统一的风格控制，避免前一步刚把语气调成沉稳专业，下一步又生成一段浮夸的表达。

这些任务如果塞进一次Prompt调用里，模型要么顾此失彼，要么在长上下文里丢失前面的约束，最后产出一份"看着完整、实际到处是洞"的简历。更麻烦的是没法定位问题：用户说"这里写得不对"，你要是不拆Agent，连是哪里出的错都不知道，只能整体重跑一遍，运气成分太大。

所以我的结论很直接：单次调用是玩具，多Agent协作才是生产级方案。不是"多个模型各写一段然后拼接"那种伪协作，而是每个Agent负责一个边界清晰的子任务，通过编排层串联，共享状态，让每一步的输出都成为下一步的输入约束。

2. 整体架构设计：一个One-Pass流水线，而不是所有Agent一哄而上

2.1 四个核心Agent的职责划分与依赖关系

我的方案里一共四个Agent，各自承担一类任务，按流水线方式串联：

这四者的依赖关系是严格单向的：解析→匹配→重构→合稿。不搞"所有Agent都能互相喊话"那种花哨设计，原因后面讲。

2.2 状态共享：用一张"简历状态表"贯穿全程

架构上最容易被忽略、但最关键的，是Agent之间怎么传递数据。很多人喜欢让Agent输出自然语言，然后下一个Agent去"理解"上一步的自然语言，这是极其脆弱的做法。

我的做法是定义一个强类型的中间状态结构，我称之为简历状态表（ResumeState），它的核心字段长这样：

# resume_state.py RESUME_STATE_SCHEMA = { "user_identity": {"name": "", "phone": ""}, "experiences": [ { "id": "exp_001", "company": "某公司", "role": "运营经理", "time_start": "2021-06", "time_end": "2023-02", "raw_description": "负责用户增长，做过社群活动", "structured_achievements": [], "quantified_rewrite": "", "matched_keywords": [], "missing_fields": [] } ], "jd_keywords": [], "match_report": {"overall_score": 0, "gaps": []}, "final_text": "" }

有了这张表，Agent之间传递的就不再是"一段话"，而是精确的字段。解析Agent负责把非结构化文本填进这张表，匹配Agent读取表里的结构字段做计算，重构Agent只修改quantified_rewrite字段，合稿Agent只读最终字段做排版。每个Agent的输入输出严格受Schema约束，这也意味着任何一个环节出了问题，都能靠检查状态表精准定位。

3. 解析Agent：把口语化经历变成结构化JSON，难点不在抽取而在容错

3.1 用两步抽取替代一步到位的JSON输出

解析Agent是所有环节的入口，它负责把用户这句"我在某公司做了三年运营，负责用户增长，做过社群活动"变成上面那张状态表里的结构化字段。但你会发现一个尴尬的事实：让大模型直接输出最终JSON，经常会有字段缺失，尤其是时间格式、经历边界这类细节容易乱。

我的做法是拆成两步：

第一步，让模型输出经历切分结果，把用户一大段描述按"公司+时间段"切成分立条目，这个任务简单，准确率高；

第二步，针对每个条目单独做字段抽取，同时校验必填项是否齐全。这一步才涉及时间格式矫正（比如用户写"21年6月到23年2月"，需要正则和模型配合转成2021-06标准格式）和去重。

3.2 必填字段校验要交给代码，别交给模型自觉

这里有个大坑：大模型不会主动提醒你"缺了数据"。用户只说"做过社群活动"，它往往直接补一个achievement: ["提升了社群活跃度"]——这个"提升"是模型瞎编的，没有数据支撑。

我的解法是把校验逻辑从模型里拿出来，放进代码里。规则很简单预设四类必填字段：时间范围、角色、公司、以及至少一个可量化结果或具体动作。如果某字段缺失，解析Agent不硬编，而是在状态表的missing_fields里登记，后续由匹配Agent统一触发追问。

# 伪代码：校验逻辑 REQUIRED_FIELDS = ["time_start", "time_end", "role", "company"] def validate_experience(exp: dict) -> list[str]: missing = [] for field in REQUIRED_FIELDS: if not exp.get(field): missing.append(field) # 量化成果检查：如果没有数字或具体量词，也算缺失 if not has_quantified_metric(exp.get("raw_description", "")): missing.append("quantified_result") return missing

这一步的经验是：凡是能用代码确定性判断的，就不要指望模型"想起来"。Agent的价值是理解语义和处理需要推理的部分，而格式校验、必填检查这种确定性逻辑，交给规则才能保证稳定。

4. 匹配Agent：招聘JD和经历之间的"翻译官"，比想象中更需要领域知识

4.1 关键词匹配为什么不直接查字典

匹配Agent做的事，是拿JD里的要求去对照用户的经历，找出gap。表面上看，这不就是字符串匹配吗？JD写了"数据分析能力"，简历里没出现这几个字，是不是就匹配失败？实际上完全不行，因为简历里可能写的是"搭建了转化漏斗，通过A/B测试优化落地页"——这明显是数据分析能力，但字面上一个关键词都对不上。

所以匹配Agent不能做词面匹配，要做语义匹配。我的做法是把JD关键词和每条经历项分别编码成向量，计算相关性，但光有向量还不够，还要加一层领域规则：比如JD提到"增长"时，经历里相关项包括"用户获取""转化率""裂变"等；JD提到"管理"时，"带团队""下属""汇报线"都算相关。这层规则可以通过一个领域词典来维护，也可以让匹配Agent基于大模型生成候选同义词后再人工确认。

4.2 匹配报告要输出什么结构

匹配Agent的输出不是"匹配/不匹配"这种二元结论，而是一份结构化的匹配报告，包含三个维度：

• 覆盖度高：JD里的核心关键词，有多少能在用户经历中找到语义对应项；
• 缺口列表：哪些JD要求，用户完全没有对应经历，这是面试时要重点准备或简历里需要补写的；
• 误差预警：哪些匹配是"弱匹配"，比如JD要求三年经验，用户只有一年，这类预警要直接写进报告，后续重构Agent要谨慎处理，不能靠改时间造假。

这份报告一旦生成，就写进状态表的match_report字段里，重构Agent和合稿Agent都会引用它。这也是Agent协作的好处：匹配结果不只是给人看的结论，更是后续Agent的工作依据。

5. 重构Agent：量化改写不是让简历看起来厉害，而是要"可被验证"

5.1 从"形容词堆砌"到"数字+动词+结果"

重构Agent是整个系统里最容易出效果、也最容易出安全事故的地方。为什么说安全事故？因为很多初版Demo在这里翻车——模型一拿到用户平淡的描述，就像打了鸡血一样，把所有形容词都换成最高级："极大提升了""全面优化了""显著增长了"，关键是这些形容词背后没有任何支撑。

我要求重构Agent严格遵循**"动词+对象+量化指标/可验证结果"**的三段式模板。举例说明：

用户原文："负责用户增长，做过社群活动。"

重构前（反面）："负责制定并执行全面的用户增长策略，通过创新的社群活动显著提升了用户活跃度和品牌影响力。"

重构后（正面）："策划并落地12场社群主题活动，新增私域用户超2000人，社群月度活跃率从15%提升至23%。"

区别在哪？每个数字都可以被追问，每个动作都有边界。哪怕用户原始描述里没有数字，重构Agent的任务也不是编造，而是主动发起追问——你的重构输出里应该包含"建议确认：以上数字为估算，请根据实际情况核实"这样的提示。我在流程里甚至专门为这个做了个追问开关：当状态表里quantified_result缺失时，重构Agent会生成一个"互动确认"型回复，而不是强行完成。

5.2 重构前后的原意保持：把"忠实度"变成一个可计算的指标

这是生产级方案和Demo最不一样的地方。Demo只需要看起来好看，生产级必须保证改写后不能改变原意——用户说自己"负责活动执行"，你不能改写成"统筹活动全局，主导一切决策"。

我的办法是加一个忠实度校验环节，用一个轻量级的交叉验证来实现。重构Agent输出改写文本后，把它拆成若干原子事实（比如"策划12场活动""新增2000用户"），再把这些原子事实与原经历描述做一次双向匹配：

• 从原文本到新文本的覆盖率：原经历里的所有核心事实，是否都能在新文本中找到对应表达；
• 从新文本到原文本的支撑率：新文本里的每个数字、每个结论，是否能从原经历或用户确认信息里找到依据。

只有两个比例都合格，重构结果才被允许进入下一环节。这个校验可以用另一个模型来做，成本可控，但能挡掉最伤简历可信度的一类错误。

6. 合稿Agent与最后的"人机校验环"：排版只是绕不开的必要不充分条件

6.1 合稿不是模板填充，而是"按模块校验再拼接"

等重构Agent把所有经历条目都改写完毕，合稿Agent开始工作。它做的事包括：选择排版模板（按行业分技术类、运营类、管理类等）、控制全文整体字数、统一时态和语气、以及最关键的一步——检查重构后的内容是否有重复表述或相互矛盾的数字。

比如两条经历都写"提升20%"，合稿Agent得能识别出这种重复，并给出调整建议。这不仅需要模板知识，还需要对全文做个全局一致性检查。

6.2 人机校验环：生产级方案里，最后一关永远是"人"

我必须泼一盆冷水：不管Agent设计得多完善，没有任何一个自动生成系统能在无人校验的情况下直接输出生产级简历。原因很简单——简历的本质是一个人对自己的公共承诺，一旦投出去，每一句话都可能被追问。所以我的架构里最后的输出永远经过一道"人机校验环"：

系统生成完整简历后，附上一份"建议确认清单"，列出所有需要用户亲自确认的内容，包括：所有数字是否与真实情况一致、缺失的时间段是否需要补充、以及匹配报告里提到的弱预警项是否要做策略性调整（比如换一种表达方式而非填虚假经历）。用户确认后，才生成最终PDF。

这一步并不是妥协，恰恰是多Agent架构里最专业的一环。一个真正理解业务的设计者，不会把"全自动"当作卖点，而会把"自动完成90%，让人只把精力花在最后10%的关键核对上"当作专业性的体现。

7. 面试考察点拆解：面试官在"多Agent协作"这个问题上真正想听什么

7.1 从"我会调API"到"我能设计协作边界"的跨越

标题里说了，这是大厂技术面试必掌握的技能。为什么面试官对"多Agent"这么执着？因为单Agent的Prompt调优已经成了人人都能上手的基础技能，而多Agent协作考察的是更深一层的东西：你怎么把一个复杂问题拆成边界清晰的子问题，又怎么让这些子问题在协作时不互相污染。

具体到面试现场，我建议你在作答时突出下面这条思考链："与其把任务全部塞进一个超长Prompt，不如拆成四个Agent，因为每个Agent单独测试的确定性更高；Agent之间的耦合靠状态表而不是靠自然语言，因为只有强类型数据才能被验证和追溯；最后一定要有人工校验环，因为技术方案的终点不是输出文本，而是交付一份用户敢签名的文档。"

这套回答里，面试官能听到三个关键词：任务分解、状态解耦、风险兜底，这三样正是生产级系统设计的核心。

7.2 容易被追问的细节点：提前准备好这两个坑的答案

面试官大概率会在你讲完架构后追问细节。这里有两个高频追问，我先替你把答案备好。

第一个追问是："为什么不用LangGraph这类现成的多Agent框架？"我的建议答法是：框架只是工具，我关心的是自己的Agent之间的数据协议是否清晰、可否单测、可否定位故障，框架选型在方案确定之后。当然，如果你实际用了某个框架，就如实介绍你的取舍；没用的，别硬蹭。

第二个追问是："多个Agent并行不行吗？为什么必须流水线？"你的答案可以落在：有些任务天然需要前序结果（比如重构必须先知道匹配缺口），强行并行只会增加协调成本，而流水线把每一步的输入输出都变成可复现的中间产物，定位问题时你能准确说"重构Agent的第3步出了问题"，而不是"整个系统挂了"。这个表达能力，恰恰是生产级和玩具Demo的分水岭。

7.3 面试前的练手建议：用一个最小案例跑通状态表闭环

最后给面试准备一个实操建议：不用一上来就做完整的四Agent系统，先用最小实现跑通"状态表闭环"——写两个Agent，一个负责解析，一个负责重构，中间用一张JSON状态表传递数据，再加上一个非常简单的规则校验器。把这个最小闭环跑稳之后，你就能深刻理解Agent协作的核心体验：当你发现上一个Agent出的错，能在状态表里被下一个Agent和校验器兜住时，你就真正入门生产级了。

我自己的体会就是：面对这类面试题，讲得出"框架选型"的人很多，能讲清"Agent之间的数据协议和故障定位"的人很少。技术面试到最后，比的就是谁能把话说到点子上。