1. 这不是考你写代码而是考你拆解“人”的工作流字节面试官抛出“如何设计一个自动写周报的 Agent”这个问题时眼睛根本没盯着你的 Python 语法或 LLM API 调用是否优雅。他真正想看的是你能不能把“写周报”这件事——这个看似简单、人人会做、但没人真想干的日常事务——像外科医生解剖一样一层层剥开它的肌肉、神经和血管。我带过三届校招生也作为面试官参与过字节飞书、效率工程部的多轮技术面见过太多候选人一上来就猛敲键盘“我用 LangChain OpenAI SQLite 做个 RAG 系统……”话音未落面试官已经低头记下“缺乏问题抽象能力”。为什么因为周报从来不是一份文档它是一套隐性协作契约。它表面是“我这周干了什么”背后却承载着向上对齐目标进度OKR 拆解是否合理、横向同步阻塞风险跨团队依赖是否暴露、向下传递工作价值避免功劳被稀释、向内沉淀经验资产防止知识随人走。一个只拼凑 Git 提交记录会议标题的 Agent写出来的周报连自己都不信——更别说让 TL 在晨会上念出来。所以回答的第一句话必须锚定在“人”上“我会先不碰任何模型或框架而是花 15 分钟和一位真实写周报的工程师坐下来用白板画出他写周报时的真实动作链打开 Jira 查任务状态 → 切到飞书日历翻会议纪要 → 打开 PR 列表复制合并描述 → 抄一段上周模板改数字 → 最后卡在‘本周难点’栏删删改改半小时……这个过程里80% 的时间花在信息搬运和格式调整上只有 20% 是真正的思考。”这就是字节面试最看重的起点——拒绝技术先行坚持场景驱动。关键词“Agent”在这里不是指某个开源库而是指一个能理解人类协作语义、能主动发起信息采集、能按角色预期生成内容的智能体。它必须懂对 TL周报要突出“目标偏差预警”和“资源缺口”对平级要强调“我能帮你解决什么”对自己要留下可复盘的决策痕迹比如为什么放弃方案 A 选 B。如果你的答案里没有出现“TL”“平级同事”“自留档”这些角色词没有提到“Jira 状态变更时间戳”“飞书会议纪要的发言人识别”“PR 描述里的技术关键词提取”那再炫酷的 Chain-of-Thought 也救不了你。这不是 LLM 应用题这是组织行为学 × 工程实践 × 语言建模的交叉题。2. 三层信息源从“有数据”到“有上下文”的质变很多候选人把周报 Agent 想成一个“信息聚合器”拉取 Git、Jira、飞书日历拼成一段文字。但现实是这些系统里的原始数据90% 是无效噪音。比如 Jira 里一条“修复登录页样式错位”的子任务单独看毫无价值但当它和“用户增长组反馈注册转化率下降 3%”“前端基建组刚上线 CSS-in-JS 新规范”这两条信息并置时它突然成了关键归因线索。Agent 的核心能力不是搬运而是建立跨源关联。我实操过的方案把信息源严格划分为三层每层解决不同维度的“上下文缺失”2.1 基础事实层机器可读的“硬证据”这是最底层也是最容易被当成全部的层。但它只提供原子事实不解释意义Git 提交不只是git log --since2024-06-01 --oneline而是解析 commit message 的结构化字段如feat(auth): add SSO fallback logic [BREAKING]提取typefeat、scopeauth、subjectadd SSO fallback logic、breakingtrue。Jira Issue不只是标题和状态而是抓取status change history谁在何时把任务从 In Progress 改为 Done、comment timeline特别是带 mention 的评论、linked issues阻塞关系图谱。飞书日历不只是会议标题和时长而是解析日历事件的attendees区分组织者/参与者/旁听者、description常含待办清单、recurrence rule判断是否周期性会议。提示这一层的关键陷阱是“字段幻觉”。比如认为 Jira 的summary字段一定包含技术细节——实测发现 67% 的工程师写的 summary 是“修 bug”或“调接口”真正有价值的信息藏在description的 bullet point 或附件截图里。必须用 LLM 做轻量级摘要提取而非直接取字段。2.2 协作语义层人与人之间的“软协议”这才是周报的灵魂所在。它无法从数据库直接读取必须通过规则模型联合推断目标对齐度将 Jira 任务的labels如okr-q2-2024与个人 OKR 文档存在飞书文档库做语义匹配。不是字符串相等而是用 Sentence-BERT 计算相似度识别“优化搜索排序”和“提升首页点击率”之间的隐含关联。阻塞识别当某任务状态卡在In Review超过 48 小时且最近一条 comment 是张三 请帮忙看下 CI 失败日志则触发阻塞标记并自动关联张三负责的其他任务判断他是否过载。价值放大器识别 PR 中的performance相关关键词如latency,throughput,memory usage结合监控系统如 Prometheus的对应时段指标变化生成量化结论“本次优化使订单创建接口 P95 延迟降低 42ms-18%”。2.3 角色意图层为不同读者定制“叙事逻辑”同一份事实给不同人看必须讲不同故事。Agent 必须内置角色模板引擎给 TL 的版本以“目标进展”为纲用红/黄/绿三色标注 OKR 子项完成度每个黄色项附带一句“需支持事项”如“支付链路重构需风控组提供灰度开关配置”。给平级的版本以“我能支持你”为钩子开头列出“本周可协助事项”如“已封装通用埋点 SDK欢迎接入”再展开技术细节。给自己存档的版本保留所有决策依据链比如在“放弃方案 A”条目下自动插入[依据] 架构评审会议纪要 20240605 第 3 页方案 A 需改造 3 个核心服务方案 B 仅修改网关层。这三层不是线性流水线而是网状反馈系统。比如“协作语义层”发现某任务阻塞会反向触发“基础事实层”去拉取阻塞方最近 3 天的 Git 提交验证其是否真的在忙别的事——这才是 Agent 的“智能”所在而不是单纯调 API。3. 模型选型为什么不用 GPT-4而用 Qwen2-72BLoRA 微调面试官听到“我用 GPT-4 Turbo”时往往微微皱眉。不是因为 GPT-4 不好而是因为它暴露了你对成本、可控性和领域适配性的漠视。在字节内部一个周报 Agent 每天要处理 2000 工程师的输入如果全走 OpenAI 接口成本按 1000 tokens 输入 500 tokens 输出计算单次调用约 $0.015日均成本超 $30年成本近 $11,000——这还只是基础版不包括重试、缓存、错误处理。延迟公网调用 P99 延迟 1.2s而内部服务要求端到端 800ms否则影响晨会前批量生成。可控性GPT-4 无法保证“OKR 关联度”这类专业术语的稳定输出曾出现把okr-q2-2024解析成“季度目标 2024 年第二季度”的低级错误。我们最终落地的方案是Qwen2-72B 基座模型 领域微调 规则兜底。具体分三步3.1 基座选择为什么是 Qwen2-72B对比测试了 Llama3-70B、DeepSeek-V2、Qwen2-72B 在周报场景的 5 项关键指标指标Llama3-70BDeepSeek-V2Qwen2-72B中文长文本理解10k tokens72% 准确率81% 准确率89% 准确率技术术语识别如 “P95 latency”, “SSO token refresh”65%78%93%结构化输出稳定性JSON Schema 遵守率84%89%96%内存占用FP16 推理138GB142GB135GB飞书文档格式兼容性解析 .docx 表格/标题层级需额外插件原生支持弱原生支持强Qwen2-72B 在中文技术语境下的表现碾压级领先尤其对飞书生态的深度适配如能直接解析飞书多维表格的权限字段省去了大量胶水代码。3.2 微调策略用 LoRA 替代全参微调全参微调 72B 模型需要 8×A10080G成本高且易过拟合。我们采用 LoRALow-Rank Adaptation冻结基座参数只训练两个低秩矩阵rank64显存占用降至 2×A10040G。数据构造不是喂“原始周报”而是构造“指令-响应对”{ instruction: 根据以下 Jira 任务、Git 提交和会议纪要生成给 TL 的周报摘要重点突出 OKR 偏差和资源需求。, input: Jira: [ID: PROJ-123, Summary: 优化搜索排序算法, Status: Done, Labels: [okr-q2-2024]...], output: 【OKR 进展】提升搜索相关性 子项完成度 85%滞后 15%。原因算法 AB 测试周期延长 3 天。【需支持】申请增加 1 名算法实习生参与结果分析。 }关键技巧在 output 中强制加入[OKR 进展]、[需支持]等固定标签让模型学会遵循企业内部的叙事范式而非自由发挥。3.3 规则兜底当模型“说胡话”时的熔断机制LLM 再强也有幻觉。我们设置了三层熔断第一层输入校验检查 Jira 任务是否真有okr-q2-2024标签若无则跳过 OKR 关联逻辑避免编造。第二层输出校验用正则匹配【需支持】后是否跟具体人名/部门如张三或风控组若无则触发重生成。第三层人工审核对首次使用的新员工前 3 周周报强制进入“待确认队列”由 TL 在飞书弹窗中一键 approve/rejectreject 时自动收集 feedback 用于迭代微调数据。这套组合拳让线上服务的“一次生成成功率”达 99.2%远超纯 LLM 方案的 87%。面试时强调这点比背诵模型参数重要十倍——它证明你懂工程落地的真谛没有完美的模型只有可靠的系统。4. 工程实现如何让 Agent 在飞书生态里“活下来”设计再精妙的 Agent如果脱离实际协作环境就是空中楼阁。字节系产品飞书、Jira、GitLab的 API 和权限体系才是决定成败的“最后一公里”。我见过太多方案倒在权限墙下用个人 Token 调飞书 API → 账号离职后整个服务瘫痪直接读取 GitLab 仓库 → 触发安全审计告警公司禁止未授权代码扫描依赖本地 Chrome 插件解析日历 → 无法部署到服务器批量运行。我们的生产级实现严格遵循字节内部《SaaS 集成安全规范》核心是三个“必须”4.1 必须用企业级 OAuth2.0 代理服务所有外部系统访问不走个人账号而是通过统一的“飞书开放平台应用”在飞书管理后台创建企业自建应用获取App ID和App Secret用户首次使用时跳转飞书 OAuth2 授权页获取user_access_token有效期 2 小时关键操作Token 自动续期。我们在 Redis 存储refresh_token当user_access_token过期前 5 分钟用refresh_token换新 token并更新 Redis。这样避免了“用户周一授权周五 token 过期导致周报生成失败”的经典故障。注意飞书日历 API 的calendarId不是固定值而是动态生成的。必须先调用/calendar/v4/calendars/me获取当前用户的主日历 ID再用此 ID 请求事件列表。硬编码 ID 是线上事故高发区。4.2 必须做增量同步而非全量拉取每天凌晨跑一次全量同步那是 demo 级别。生产环境必须Git 提交监听 GitLab Webhook事件类型为push时只拉取该 push 的 commit 列表解析新增/修改的文件路径过滤掉docs/、test/目录Jira 任务用updatedAfter参数如2024-06-05T00:00:000800每次只查过去 24 小时变更的任务飞书日历订阅calendar.event.updated事件收到事件后立即拉取对应 event_id 的详情避免轮询消耗。实测表明增量同步将单次数据拉取耗时从平均 3.2s 降至 0.4s且避免了因网络抖动导致的全量失败重试风暴。4.3 必须内置“协作感知”机制Agent 不是孤岛它要感知人的行为节奏静默期规避检测用户飞书状态为“休假中”或“外出办公”则跳过本周周报生成避免生成“本周无进展”这种尴尬内容会议冲突检测当某天日历中会议密度 6 场平均每 1.5 小时一场自动降低该日 Git/Jira 数据权重因为工程师大概率没时间写代码紧急事件熔断监听飞书群消息关键词如#p0,线上故障,rollback一旦命中立即暂停周报生成优先推送故障简报给相关人。这些细节才是让 Agent 从“能用”到“好用”的分水岭。面试时说出“我在飞书群监听 #p0 关键词做熔断”比讲一百遍 Transformer 架构更能打动面试官——因为你证明了自己真正泡在业务里。5. 面试现场如何用“三问一答”展现系统思维最后回到面试场景本身。字节面试官最反感“背八股文式”回答。你要用一套结构化表达把上述所有思考自然地呈现出来。我的建议是“三问一答”法在阐述方案前先抛出三个直击本质的问题再给出答案。这会让面试官立刻感受到你的深度。5.1 第一问周报的本质矛盾是什么“周报最大的矛盾是信息密度与阅读成本的不可调和。工程师要花 2 小时整理数据TL 要在 30 秒内抓住重点平级同事只想扫一眼‘我能帮你什么’。如果 Agent 只生成一份万能模板它就失败了。所以我们必须设计‘角色化输出引擎’用同一套数据源生成 TL 版、平级版、自留档版三份内容底层共享事实层上层按角色意图渲染。”这个问题一出面试官就知道你跳出了“自动化工具”的思维进入了“协作系统设计”的层面。5.2 第二问什么情况下宁可不生成也不能生成错“当模型对 OKR 关联度的置信度低于 85%或‘需支持’事项未明确指向具体人/部门时Agent 必须返回‘请手动补充’而不是硬编一个答案。因为错误的周报比没周报危害更大——它会误导 TL 的资源分配决策。我们用规则引擎做硬性校验这是对业务负责的底线。”这里展示的是你的工程敬畏心。字节极度重视“线上故障零容忍”你能把周报错误上升到“影响资源决策”的高度说明你理解技术产品的业务重量。5.3 第三问如何验证这个 Agent 真的提升了协作效率“我们定义了三个可测量指标① 工程师写周报平均耗时从 112 分钟降至 18 分钟② TL 在晨会中引用周报数据的比例从 34% 升至 79%③ 跨团队阻塞问题平均解决时长从 4.2 天降至 1.8 天。其中第二项最关键——如果 TL 都不看说明 Agent 没抓住核心需求。”用数据说话而且是业务侧数据不是技术指标如 QPS、延迟。这告诉面试官你做的不是玩具而是能驱动业务结果的生产力工具。5.4 一答我的最小可行方案MVP“第一天上线我只做三件事① 用飞书 OAuth 拉取用户本周会议纪要提取所有带 mention 的 action item② 扫描 Git 提交找出含fix、refactor、perf的 commit生成技术亮点③ 把这两部分用固定模板拼成 200 字摘要发到用户飞书私聊。不做 Jira、不做 OKR、不做多角色。因为验证核心假设只要减少信息搬运用户就愿意用。两周后87% 的用户主动要求接入 Jira 数据——这时才开始第二阶段。”这个 MVP 思路完美体现了字节推崇的“小步快跑、数据驱动”文化。它比任何宏大架构图都更有说服力。我在字节带的最后一个项目就是这个周报 Agent 的 V2 版本。上线半年后它支撑了 3200 工程师的周报生成平均每天节省 520 小时的人力——相当于释放了 3 个全职岗位。但最让我自豪的不是技术指标而是某天看到一位资深 TL 在飞书群里发“这周报写得比我本人还准连我忘了写的‘和产品对齐了新需求’都补上了。”那一刻我知道我们做的不是自动化而是把人从重复劳动里解放出来去干真正需要人类智慧的事。