我来梳理这份实现计划干的事情。先确认当前src的结构,这样能准确对照计划。看来这个计划已经部分落地了——prompts/有slot_clarification.md和respond.md,config/keyword_map.yaml已存在,evals/intent/已创建。我先快速确认实际现状,再给你完整的设计梳理。好的,代码现状已清楚。这份计划的大部分 Task已经落地(intent.py 已是 v2,provider.render() 已存在,keyword_map.yaml 已落地)。我来给你梳理这次设计到底干了什么。一句话概括把intent节点从「裸 query 喂给 LLM → 关键字兜底」升级成「结构化 Prompt 候选动态注入 槽位澄清 YAML 配置 Eval 基线」——同时保证向后兼容(旧调用方传None仍能跑)。改造前 vs 改造后维度改造前改造后LLM 收到的裸query字符串完整渲染的 Prompt(含候选清单表格 输出格式约束)LLM 输出格式[agent1,agent2]简单数组{intents:[{agent:...,slots:{...},missing_slots:[...]}]}结构化意图候选来源硬编码在节点里从config/supervisor.yaml动态读取缺信息处理直接进 planner 走错误流程走slot_clarification.md主动追问KEYWORD_MAP写死在intent.pyconfig/keyword_map.yaml 同义词 chitchat 多意图开关chitchat 处理无特殊处理,可能误触发澄清命中领域 Agent 时自动忽略 chitchatEval无50 条 seed(40 标准 10 对抗),可跑关键词基线Respond 提示词graph.py里硬编码字符串提取到prompts/respond.mdrender()注入6 个 Task 各自干了什么Task 1 — 给 PromptProvider 加render()目的:让 prompt 文件里的{{var}}占位符能被代码动态替换。之前provider.py只有get()(读原文),现在加了render():读模板 → 字符串替换 → 未替换的{{var}}记 warning(见src/prompts/provider.py:67-78)。注意实现时还做了个小增强:re.findall检测残留占位符告警——比计划里写得更好。Task 2 —models.py新增IntentCandidate新增一个 TypedDict 描述「候选意图」:agent/domain/description/examples/required_slots。required_slots是关键——比如订会议室必填time/count,这就是后面槽位追问的依据。Task 3 — intent 节点主改造(最核心)3 件事:Prompt 接线:LLM 不再吃裸 query,而是吃render(intent_recognition, {候选清单表格, 历史消息})渲染后的完整 prompt。候选清单用_render_candidates_table()渲染成 Markdown 表格(含「必填信息」列),让 LLM 一眼看出每个意图需要哪些槽位。结构化解析_parse_intents_v2:解析 LLM 返回的{intents:[{agent,slots,missing_slots}]};兼容旧格式[agent1](自动补slots{}、missing_slots[]),所以老测试不破。槽位澄清:只要任一意图的missing_slots非空,needs_clarificationTrue→ 图的条件边短路到respond→ respond 里先检查missing_slots,用prompts/slot_clarification.md渲染追问 prompt,LLM 失败兜底为「请提供:time, count」。Task 4 — KEYWORD_MAP 升级到 YAML新增KeywordEntry(含keywordssynonyms)和KeywordMapConfig(含multi_intent_enabled开关)。load_keyword_map(path)从 YAML 加载,YAML 缺失/损坏回退内置硬编码(Fail-Safe)。同义词:饭堂也能命中canteen-agent(只靠主关键词会漏)。chitchat 关键词单独维护,避免你好被误判成需要澄清。多意图开关:multi_intent_enabledfalse时只返回首个命中(单意图模式)。Task 5 — Eval 数据集 seed50 条 JSONL(40 标准 10 对抗),让「关键词基线准确率」可以客观测量(对比 spec §2.2.2 的 92%/95% 阈值)。Task 6 — 端到端验证跑 pytest ruff mypy 关键词 Eval 基线脚本。设计上的几个亮点(值得学习)三层降级链(Fail-Safe 红线 AGENTS §0.3):LLM Prompt 候选清单 → LLM 裸 query → KEYWORD_MAP → 空意图(走澄清)每层挂掉都能跑,永不抛异常给 LangGraph。向后兼容的签名演进:recognize_intent新增的prompt_provider/intent_candidates/keyword_map全是关键字参数且默认None,老调用方一个字都不改就能继续用——这是外科手术式修改(AGENTS §3)的典范。Prompt 外置 动态注入(AGENTS §0.3 AI 红线):prompts/intent_recognition.md升级输出格式prompts/slot_clarification.md追问模板prompts/respond.md提取graph.py里的硬编码 prompt全部经render()注入,代码里不再出现 prompt 文本。chitchat 智能过滤(_filter_chitchat_when_domain_present):“你好帮我订会议室” 这种复合句,既命中 chitchat 又命中 meeting-agent,系统选领域 Agent、丢弃 chitchat——避免无意义的澄清。missing_slots显式长度检查(见intent.py:273-276注释):用len(i.get(missing_slots) or []) 0而非 truthy,区分None(键缺失)与[](空列表)——比计划里写得更严谨。一个值得注意的实现偏差计划 Task 3 Step 4 写的是 LLM 调用await llm(prompt_text)(只传渲染后的 prompt);但实际代码intent.py:254是await llm(query, system_prompt)——传了两个参数(query system_prompt)。这意味着 LLM hook 的签名从Callable[[str], Awaitable[str]]变成了Callable[[str, str], Awaitable[str]]。这个偏差改变了 LLM hook 的契约,如果llm_intent的实现方(在src/common/llm_hooks.py或工厂层)还按旧签名写,会报参数错。要不要我顺便检查一下llm_hooks.py的实际签名,确认这个偏差有没有被同步对齐?