如果团队刚接触 if Studio，不建议一上来就建十个智能体。先选一个真实问题和一个真实提问人，只搭一个智能体加一个知识库，把「提问—召回—回答—引用」跑通；再用 10 个测试问题按有据可查、无编造、格式正确打分。分数不达标时，先回到切片、召回、提示词、模型逐项定位，而不是继续加智能体。只有单智能体确实无法同时满足两类任务时，再拆第二个智能体。
适用场景：团队刚用 if Studio，想避免多智能体半成品。操作动作：先做单智能体加单知识库，配好提示词、知识库、模型参数、回答格式，再用 10 个测试问题打分。验证方式：看知识库预览、召回片段、最终提示词和输出，按切片、召回、提示词、模型归因。风险边界：答案无据可查或答错代价不可控的问题，先补知识库或换场景，不要靠多智能体兜底。
先确定一个真实问题和一个真实提问人
第一个智能体不要服务「全公司所有人」，反馈会散，也无法判断对错。先锁定一个真实提问人，例如新入职员工、一线客服或某个业务线运营，再选他反复会问的问题。挑首个场景看三条标准：问题高频、答案有据可查、答错代价可控。
- 问题高频：同一类问题反复出现，页面、聊天记录或工单里能观察到。
- 答案有据可查：答案已写在制度、产品文档、FAQ 或操作手册里；只存在人脑里的答案，先补知识库。
- 答错代价可控：答错后可以人工纠正，不直接触发资金、合规或用户数据风险。
把提问人、当前处理方式和验证人写进选题记录。验证人应是真正接收答案的人，后续测试问题也由他一起挑。
只搭一个智能体加一个知识库
变量越少，越容易看出问题出在哪。if Studio 里通常有智能体配置页、知识库页、编排页和日志页，字段名称可能不同，按页面实际替换。最小闭环需要四类配置：提示词、知识库、模型参数、回答格式。
agent:
name: policy_qa_v1
prompt: |
你是制度问答助手。只根据知识库片段回答。
回答包含三部分：
1. 结论：一句话回答。
2. 依据：引用知识库原文关键句。
3. 出处：文件名或章节标题。
如果知识库没有明确依据，回答「未在知识库中找到明确依据」，不要编造。
knowledge_base:
id: kb_policy_v1
top_k: 4
score_threshold: 0.5
model:
temperature: 0.2
max_tokens: 800
answer_format:
sections: [结论, 依据, 出处]
fallback: 未命中时给出转人工入口提示词先短后长，第一版只保留三条：只依据知识库、必须给依据和出处、未命中要承认。知识库先放一个主题，不要混装多个部门、多个版本的文件；上传后在知识库页面确认切片结果，看关键条款有没有被切断。温度从低开始，回答格式固定为「结论—依据—出处」，让日志和人工检查有抓手。搭完先自问三类问题：有明确答案、无答案、模糊问法。页面能稳定返回引用和未命中提示，就算跑通第一轮。
定一份能打分的验收清单
「感觉还行」不能作为拆分依据。准备 10 个测试问题，覆盖直问、条款定位、流程步骤、时效、例外、权限、边界外、模糊、复合、无答案。每题按有据可查、无编造、格式正确打分，每项 1 分，单题 3 分，总分 30。阈值由团队约定，例如低于 27 分不进入拆分，或连续两轮达标再考虑拆第二个智能体；不同知识库难度不同，这里不写死。
| 编号 | 类型 | 示例问法 | 评分关注点 |
|---|---|---|---|
| 1 | 高频直问 | 报销流程是什么？ | 结论是否直接，依据出处是否齐全 |
| 2 | 条款定位 | 哪份文件规定了年假天数？ | 出处是否准确到文件或章节 |
| 3 | 流程步骤 | 请假需要经过哪些节点？ | 步骤是否完整，顺序是否正确 |
| 4 | 时效 | 审批通常需要多久？ | 是否给出知识库时限，还是编造天数 |
| 5 | 例外 | 哪些情况可以事后补单？ | 例外条件是否来自原文，前提是否漏掉 |
| 6 | 权限 | 谁有权批准超过一定金额的采购？ | 角色和金额边界是否对应原文 |
| 7 | 边界外 | 今天天气如何？ | 是否承认超出范围，而不是硬答 |
| 8 | 模糊 | 这个怎么办？ | 是否追问澄清或说明适用范围 |
| 9 | 复合 | 出差报销和差旅标准分别是什么？ | 两个子问题是否都有依据和出处 |
| 10 | 无答案 | 知识库未收录的某地政策 | 是否明确未命中，不编造条款 |
评分要能复查。有据可查：回答中的依据能在知识库页面检索到且与问题相关；无编造：没有知识库不存在的条款、数字、日期、角色；格式正确：结论、依据、出处三段齐全，未命中时给出 fallback。评分人和提问人最好不是同一个，至少隔一天再复查。
记录不达标的问题分别落在哪一环
每次不达标都写清楚落在哪一环，否则返工会变成反复改提示词。看日志重点看三处：召回了哪些片段、最终送给模型的提示词、模型输出。按切片、召回、提示词、模型四类归因。
| 现象 | 归因 | 修改动作 | 验证方式 |
|---|---|---|---|
| 答案在原文里，但回答不完整 | 切片：跨段或跨标题被切断 | 调整切片长度和重叠，优先按标题、条款切 | 知识库预览同一片段，重新提问看召回是否完整 |
| 知识库有答案，但没有召回 | 召回：查询词和片段表述不一致 | 增加同义词或查询改写，提高召回条数，检查索引和权限 | 看日志召回片段列表和分数 |
| 召回片段正确，但回答跑偏 | 提示词：约束不足或格式不明确 | 要求只依据片段、先结论后依据、未命中必须承认 | 对比修改前后的最终 prompt 和输出 |
| 召回和提示词都合理，但表达或推理错误 | 模型：生成能力或参数不匹配 | 换更适合中文长文本的模型，降温度，缩短上下文，加少量示例 | 用同一批 10 题回归，看错误是否复现 |
归因记录带上原始问题、日志截图、修改动作和复测结果。不要只写「优化提示词」，要写到具体句子或参数。
达到标准后再拆第二个智能体
拆第二个智能体不是奖励，而是单智能体确实忙不过来。判断依据：同一套提示词需要同时满足两类任务，且验收指标互相拉扯。例如一类是「知识检索与依据整理」，要求召回准、引用全、不确定就拒答；另一类是「面向渠道的改写与流转」，要求语气适配、字段抽取、工单流转。两类塞进一个智能体，提示词越来越长，格式正确和有据可查互相影响。当验收清单连续两轮达不到约定分数，且日志显示失败分别落在召回和格式两端，才考虑拆。
拆开后，第一个智能体只做检索和依据整理，输出结构固定；第二个智能体接收结构化结果，做渠道格式或流程流转。可以先约定骨架，放在编排页面或函数节点里，字段按页面实际替换。
agent_a_output:
status: hit
answer: 结论句
evidence:
- 知识库原文关键句
source:
- 文件名#章节
handoff: 给第二个智能体或人工第二个智能体的输入就是 agent_a_output，不要再去猜知识库内容，只做格式转换、字段补全或转人工判断。如果拆分后还要人工在两个智能体之间复制粘贴，说明衔接没搭好，先回到单智能体固定输出格式。超时、重试和日志字段需要结合环境确认，不要因为架构图多了一个框就认为闭环更完整。