新增求职链路测试模式并修复配置重启失效 - #29
Merged
NingNing0111 merged 7 commits intoAug 21, 2026
Merged
Conversation
Contributor
|
该PR存在冲突，请解决 |
所有大模型用途都经过 AgentRunner::execute 这一个出口，埋点收在这里就等于 全覆盖，新增用途也不会漏接。每轮记下实际送出的提示词、净化后的输出、模型、 token 用量与判定结果，供测试模式调提示词。 轨迹只驻内存（环形缓冲 200 条），随进程退出即丢。日志为了不泄露简历原文 一向只留原因和长度，缺的正是调提示词最需要的那部分；但这些内容确实敏感， 所以除非用户显式导出，否则不落盘。 五条退出路径都先落轨迹再返回，其中模型调用失败原先是裸 ? 抛出的，什么都 留不下——而调用压根没成功恰恰是调提示词时最该区分的一种情况。准备阶段的 两次失败同样留痕：模板漏填变量的报错发生在循环之前，而它正是此前猎聘自动 回复整个平台静默失效的根因，轨迹为空会让页面在最该看清的地方一片空白。 with_trace_id 让调用方先拿号再跑：失败时 AgentOutcome 连同 trace_id 一起 没有了，靠"取最新一条"反查在并发跑任务时会认错人。 锁中毒时接管数据而不是 unwrap：追踪是辅助设施，一次 panic 让此后每次大模型 调用都连带 panic，等于为了看提示词把投递功能弄挂了。
三条链路各自把环节摊开返回：筛选（正则→语义复核）、打招呼（决策→序列组装 →发送体检）、回复（闸门→路由→决策→意图校正→发送体检）。每个环节给出 通过/拦截/跳过与原因，拦截的原因写成用户看得懂的人话。 全部复用真实运行的同一批函数，不另写一套判断。此前的调试入口自己拼参数还 漏了 chat_history，于是调试看到的效果和真跑出来的不是一回事——这个教训就 记在被本次删掉的那两个 debug 命令的注释里。 简历入口状态与窗口内已回复条数改为入参。旧调试页把它们写死成 Unknown 和 0， 导致意图校正和闸门的分支根本测不到，而那正是最需要复现的地方。 提示词覆盖只写进 resolve_job_profile 返回的内存副本，不落盘：AgentTask 的 prompt_template 本来就从配置读，因此改提示词立刻重跑不需要改动任何 Task。 删除 debug_generate_replay 与 debug_generate_greet，已被完全取代。 契约锁测试盯住 Stage / Outcome / ResumeState / StepReport 的线上 JSON 格式。 前端类型是照着这些字面量手写的，谁顺手加个 rename_all 编译和测试都照过， 只有界面会在用户点下去那刻悄悄渲染成空白。
三栏：左边选方案、造岗位、摆布简历状态与已回复条数；中间是流水线与聊天沙盘； 右边是 Agent 调用轨迹。 聊天沙盘可以切换身份说话，HR 与我方两种身份决定 received——这不是装饰， 它让用户能造出"最后一条是我方消息"的对话，从而触发闸门的不重复发送分支。 提示词在页面里就地编辑、立刻重跑，改动只作为 overrides 带出去不落盘， 满意了再按方案 id 写回。调提示词才是这个页面存在的理由，迭代循环不能是 "去配置中心改→保存→回来重跑"。 流水线十个环节固定全渲染，没跑到的保持灰态，用户能一眼看出链路断在第几步； 拦截原因直接铺在行下不藏进折叠区。轨迹面板按轮次切换，第二轮相对第一轮 追加的返工段做前缀比对后高亮——返工只往尾部追加，真 diff 反而会把同一句话 在两处出现标成改动。 环节产物是 unknown，全部经类型守卫收窄后渲染，任何形状都不会崩。 setup.ts 补 ResizeObserver 与 scrollIntoView 两个 jsdom 空缺，与已有的 matchMedia polyfill 同一类问题：antd 的 Tabs/Segmented 挂载即测量自身尺寸。 删除 conversation-debug 页面，能力已被完全覆盖。
parse_config_content 原本是一长串 if let Some(x) = value.get("x")，逐字段把
YAML 搬进结构体。这个写法要求每新增一个配置段都记得回来补一行，漏了不会报错、
编译通过、测试也全绿——只有用户改完设置重启后发现又变回默认值。
analysis_config、reply_polling_config、periodic_delivery_config、
humanize_config 四段就是这么整段丢掉的：保存当次一切正常（前端拿的是后端
返回的内存对象），重启走一遍解析才暴露。
改成整份反序列化，新增字段默认就能存活。手工搬运只剩三处真正的版本迁移：
v0 的明文密钥结构、greet_config 缺 enable_llm 键时的兼容、以及 v0-v2 没有
job_profiles 时从顶层镜像补方案卡。llm_config 在整体反序列化前先摘出去单独
处理，否则它的历史形态会连累整份配置一起解析失败。
补齐 browser_config / resume_config / job_filter_config / greet_config /
replay_config 的 serde 默认值来源：整体反序列化下少一个键就会让整份配置加载
失败，等于用户直接进不去应用，而逐字段搬运的老写法天生容错，这个性质得显式保住。
config_roundtrip_survives_every_section 守住这条性质，它不点名任何字段，
拿整份配置比对，以后再加配置段漏了处理会当场变红。
同一份方案卡配置在代码里有三处反向搬运：from_runtime_mirror（顶层→方案卡）、 resolve_job_profile（方案卡→顶层）、normalize_job_profiles（默认方案→顶层）。 加一块新配置要记得改三处，而 analysis_config 当初只改了前两处。 于是顶层镜像里长期躺着一份永不更新的分析策略。目前没有用户可见症状—— auto_analysis 拿到的 config 都来自 resolve_job_profile，那条路径是全的—— 但它违反了"顶层是默认方案镜像"的约定，下一个直接读顶层的人就会踩到。 顺带删掉 validate_and_normalize 里对顶层 analysis_config 的 clamp： 方案卡各自已经 clamp 过，回写顶层之后那次 clamp 的结果总是被覆盖， 留着只会让人以为顶层是一份独立数据。 top_level_mirror_matches_the_default_profile 不列举任何配置块， 而是把规整后的顶层重新投影成方案卡与默认方案整体比对， 以后新增配置块漏了同步会当场变红。
顶层页签留给日常求职主流程，测试模式作为调配置的工具收进「配置中心 · 系统能力」， 与大模型、浏览器环境并列。 页面从一屏三栏改成「选链路 → 备场景 → 看结果」三步：每趟只测一条链路， 要填什么由链路推出来，结果先给结论再给明细。岗位、对话、会话现场在三条链路间共用， 链路开关挂在场景页顶上，切链路不清空也不必回退；切到别的配置分组时页面只隐藏不卸载。
上游新增招聘者活跃时间与 BOSS 活跃度筛选后，测试模式的手工岗位和前端夹具需要补齐对应字段。手工岗位没有来源页面，活跃时间保持未知；夹具沿用主干默认筛选配置。
patrickleehua
force-pushed
the
agent/greeting-send-sequence
branch
from
August 21, 2026 06:09
e7a56af to
74678b9
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
变更内容
AgentRunner执行出口增加调用轨迹，记录实际提示词、净化后的输出、模型、Token 用量和判定结果；轨迹默认仅保存在内存环形缓冲区，只有用户显式导出时才落盘analysis_config、reply_polling_config、periodic_delivery_config、humanize_config等配置段的持久化，以及默认方案与顶层分析配置镜像的同步背景与影响
原对话调试入口自行拼装参数，曾遗漏真实链路需要的
chat_history，简历入口状态和窗口内回复次数也被写死；因此调试页面看到的结果不一定等于实际运行结果。新的测试模式直接复用生产链路中的判断与发送前体检，并把每一环的结论和 Agent 调用轨迹展开。页面内的提示词覆盖只作用于本次内存副本，不会意外改写用户配置；包含敏感上下文的调用轨迹也默认不落盘。配置重启失效的根因是旧解析器逐字段从 YAML 搬运数据。新增配置段如果忘记在解析器中再补一行，保存和编译都不会报错，前端拿到后端返回的内存对象时也表现正常，只有重启重新读取配置文件后才会静默回到默认值。本次改为整份配置反序列化，手工处理只保留真正需要的历史版本迁移，并用整份配置往返测试和默认方案镜像整体比对防止以后新增字段再次漏写。
验证
cargo test --lib：609 通过npx vitest run：202 通过npx tsc --noEmit：无错误