Chapter 11 · Domain 2（权重 18%）

工具接口设计
描述质量、拆分与合并、工具分配与最小权限

Domain 2 的核心洞见只有一句：tool description 是 LLM 选择工具的首要机制。它意味着「工具选错了」这类故障的第一嫌疑人是描述——不是模型、不是路由层、不是提示词技巧；第二嫌疑人是 system prompt 里对关键词敏感的指令。官方样题 Q2 与 Q9 都出在本章。

一、描述是接口，不是注释

模型选工具时能看到的只有名字和描述。描述简陋 → 在相似工具之间的选择就不可靠。guide 列出了一份好描述应当包含的四类信息：

要素	作用
input formats（接受什么输入格式）	让模型知道手上的标识符该喂给谁
example queries（示例查询）	把抽象职责变成可对照的具体样子
edge cases（边界情况）	说明它不处理什么
boundaries（与相似工具的区分）	直接回答「我该用这个还是那个」

# ✘ 简陋（官方样题 Q2 的原始状态）
get_customer:  "Retrieves customer information"
lookup_order:  "Retrieves order details"

# ✔ 可区分
get_customer:  "Look up a customer account by email, phone, or customer ID (format CUS-######).
                Use this FIRST to verify identity before any order or billing operation.
                Returns account status, tier, and contact info. Does NOT return order data —
                use lookup_order for anything about a specific purchase."
lookup_order:  "Look up a single order by order number (format ORD-###### or a 12-digit
                legacy ID). Use for questions about one purchase: status, items, totals,
                shipment. Requires a verified customer ID from get_customer. Does NOT search
                across a customer's order history."

三种修复手段的选择

手段	什么时候用	官方举例
扩写描述	职责本身清晰，只是没写清楚——默认的第一步	官方样题 Q2：两个工具描述各一句话，扩写即可
改名 + 改描述	名字本身在暗示重叠的职责	`analyze_content` → `extract_web_results`，并配 web 专属描述
拆分泛化工具	一个工具确实在做几件不同的事，各自有不同的 I/O 契约	`analyze_document` → `extract_data_points` / `summarize_content` / `verify_claim_against_source`

顺序有讲究（P2 比例原则）：先扩写描述，再考虑改名，最后才考虑拆分或合并。官方样题 Q2 里，把两个工具合并成 lookup_entity 是一个合理的架构选择，但作为 "first step" 过重，败给了改描述。反过来，ch01 的 P4 边界提醒：拆分不是越细越好，拆到描述能清晰区分为止——拆出两个描述高度相似的工具，只会制造新的误选。

容易漏掉的第四条 — system prompt 里对关键词敏感的指令可能覆盖写得很好的工具描述。例如 system prompt 写着「遇到 refund 相关问题优先查看账户状态」，模型就可能在明显该调 lookup_order 时去调 get_customer。guide 把「审查 system prompt 里的关键词敏感指令」单列为一条 skill——排查误选时，描述之外要看的第二个地方就是它。

二、工具分配：数量本身就是变量

guide 给了一个具体的数量对比：18 个工具 vs 4–5 个工具——工具太多会因决策复杂度上升而降低选择可靠性。这不是「模型不够聪明」，而是任何选择系统都有的性质。

与之配套的是第二条观察：拿到专业外工具的 agent 倾向于误用它（guide 的例子：synthesis agent 去做 web search）。所以工具分配的默认策略是 scoped access——每个 subagent 只拿本职工具。

例外：高频跨角色需求

官方样题 Q9 给了这个例外的标准形态：synthesis agent 在综合发现时需要核实事实，而每次核实都要绕 coordinator 走一趟。正确答案的关键词是 least privilege——给它刚好够用的那一件工具，其余照旧委派。

前提：这个口子只对既高频又简单的跨角色需求成立，频率与复杂度两条都要满足（ch01 的 P4 口诀「八成场景给小刀，两成场景走大门」）。
手段：给它一个 scoped 的 verify_fact 工具覆盖简单核查；复杂的那部分仍然经 coordinator 委派专业 agent。

前提不满足时，正确答案回到「维持委派」——本章 Q3 考的就是这一侧。官方点名的错法形态是把权限一次给足：over-provisions，违反关注点分离。

受约束的替代品

还有一条独立的手段：把泛化工具换成受约束的替代品——guide 的例子是用 load_document（会校验文档 URL）替换 fetch_url（能抓任意 URL）。它和「拆分」不同：拆分是把一个工具变成几个，替换是把同一个能力收窄到安全的子集。

工程上，工具数量的压力还有一个常被忽略的来源：MCP 服务器。所有已配置的 MCP 服务器的工具在连接时同时可用（TS 2.4），三个服务器各带 6 个工具就已经 18 个了——正好是 guide 用来举反例的数字。所以「工具太多」在实践中往往不是设计失误，而是集成的副作用。控制手段是给每个 subagent 配 scoped 的工具集，而不是少接服务器。

外部课程 · CertSafari — 本章 2 个考点（展开查看）

用于补读和错题复盘；第三方 AI 生成练习材料，非官方题库。核验答案时以 Exam Guide 和官方文档为依据。复盘方法 · 链接核对：2026-10-16。

考点回链 — 本章覆盖：TS 2.1（描述是选工具的首要机制、四类要素、重叠描述致误路由、改名消除重叠、拆分泛化工具、system prompt 关键词敏感指令可覆盖描述）、TS 2.3（工具过多降低选择可靠性、专业外工具易误用、scoped 工具分配、高频跨角色 scoped 工具 + 复杂情况走 coordinator、受约束替代品）。tool_choice 三态见 ch09。相邻考点：MCP 错误与配置见 ch12，hub-and-spoke 见 ch03。

本章题组

ch11 · Q1 · 准则 P1

Production logs show your agent calls search_kb when users ask about specific ticket numbers ("what's the status of TKT-88213?"), instead of get_ticket. Both descriptions are one line: "Searches the knowledge base" and "Gets ticket data". Both accept string identifiers. What is the most effective first step?

正确 ATS 2.1：tool descriptions 是 LLM 选择工具的首要机制，描述简陋时模型缺乏区分相似工具的依据。扩写是低成本高杠杆的第一步，四类要素（输入格式、示例查询、边界情况、与相似工具的区分）正是 guide 点名的内容。与官方样题 Q2 同构。

D3 治标不治本违反 P1B：few-shot 增加 token 开销却没修根因——描述仍然无法区分。官方样题 Q2 对 A 选项的原判就是这一条。（注意与 ch08 Q4 的区别：那里描述已经详尽、歧义是真实的，few-shot 才是正解。）

D2 过度工程违反 P2C：路由层绕开了 LLM 的自然语言理解能力，官方样题 Q2 对同类选项的原判是 over-engineered；而且前缀规则脆弱——用户说「我上周报的那个工单」时它完全失效。

D2 过度工程违反 P2D：合并是站得住的架构选择，但作为「first step」过重（官方样题 Q2 的 D 选项原判）。当前问题是描述不足，先修描述。

ch11 · Q2 · 准则 P1

You rewrote both tool descriptions with input formats, examples, and explicit boundaries. Selection improved from 61% to 74% but plateaus there. The remaining failures cluster on billing-related phrasings, where the agent calls get_account even when the user clearly names an invoice. Your system prompt contains: "For any billing question, start by confirming the customer's account standing." What should you check?

正确 BTS 2.1 的第四条：system prompt 中对关键词敏感的指令可能覆盖写得很好的工具描述，制造非预期的工具关联。题干把证据摆得很齐——失败精确地聚集在 billing 措辞上，而 system prompt 里正有一条 billing 关键词触发的指令。guide 把「审查 system prompt 的关键词敏感指令」单列为一条 skill。

D2 过度工程违反 P2A：在还没查清剩余失败的成因之前就做合并这类重构。「看起来是结构性的」正是尚未查证的猜测——题干已经把线索摆在桌上：失败精确聚集在 billing 措辞上，而 system prompt 里恰好有一条 billing 关键词指令。描述改进确实带来了 13 个点，证据指向的不是描述不足。

D4 甩锅错位违反 P1C：context 压力会造成弥散的、无模式的退化，不会造成「只在 billing 措辞上系统性走偏」这种高度结构化的失败。

D2 过度工程违反 P2D：用强制工具选择把症状压住，等于在应用层重建一个路由器，还要先判断「这是不是 billing turn」——把本该由描述解决的问题变成了新的分类问题。

ch11 · Q3 · 准则 P4

An incident-triage agent delegates every database inspection to a specialized db_agent through the coordinator. Instrumentation over 640 triage runs shows 22% of the inspections are single-row status reads, while 78% need multi-table joins, query-plan reasoning, and schema history; the delegation hop adds about 1.2 s to a triage flow that averages 45 s end to end. The triage agent's own set is already eight tools. A teammate proposes adding a ninth so the simple reads stop paying the hop. What should you do?

正确 DTS 2.3 的例外是有前提的：既高频又简单——ch01 的 P4 口诀「八成场景给小刀，两成场景走大门」说的就是这个分界。这里简单档只占两成，收益还要再乘一次：0.22 × 1.2 s ≈ 0.3 s，对 45 s 的流程不到端到端的 1%。代价却是永久扩宽 triage agent 的工具面，而占 78% 的复杂检查正是「拿到专业外工具的 agent 倾向误用」的温床（TS 2.3）。数据指向的结论是维持委派。

D2 过度工程违反 P2A：把上文那个例外的形态照搬过来，却把前提丢了——那里的简单档是绝大多数，收益随频率放大；这里频率与单次收益两个乘数都很小。为不到 1% 的端到端收益给一个角色新增常驻工具，手段与收益不成比例。

D6 概率当保证违反 P8B：把「我不需要查库」这个自我判断当成闸门。自报置信不是复杂度的可靠代理（TS 5.2），而且恰恰在难判的工单上会错误地自信；漏查一次的代价是根因判错，远不止 1.2 s。

D1 凭空捏造违反 P4C：AgentDefinition 上没有 delegation: inline 这样的字段，subagent 以隔离上下文运行、经 Task 委派（TS 1.3）。而且这个机制若真的存在，等于把专业外工具全量塞进 triage 的选择空间，比 A 更远离最小权限。

ch11 · Q4 · 准则 P4

Your code-exploration agent has a fetch_url tool used to pull documentation pages. In testing, the agent occasionally uses it to hit internal admin endpoints discovered in config files. You want to keep the documentation capability. What is the appropriate change?

正确 ATS 2.3 点名的 skill：用受约束的替代品替换泛化工具，guide 的原例正是 fetch_url → load_document（校验文档 URL）。约束在工具实现里，不依赖模型自觉——保留了能力，收窄了权限面。

D6 概率当保证违反 P3B：把访问控制押在 prompt 措辞上是概率性合规。内部管理端点属于「误操作有实际后果」的范畴，需要确定性机制。

D4 甩锅错位违反 P2C：把负担转嫁给开发者，并且直接废掉了题干明确要保留的能力。为了消除一个可以被约束的风险而放弃整个功能。

D6 概率当保证违反 P3D：描述影响的是选择倾向，不构成执行期的边界。写得再清楚，工具本身依然能抓任意 URL。

ch11 · Q5 · 准则 P4

Your document-analysis subagent exposes one tool, analyze_document, described as "Analyzes a document and returns findings." Callers use it for three different purposes: pulling numeric data points, producing summaries, and checking whether a specific claim is supported by the source. Output shape varies unpredictably and downstream parsing is unreliable. What should you do?

正确 CTS 2.1 的原例逐字命中：把泛化的 analyze_document 拆成带明确 I/O 契约的专用工具 extract_data_points / summarize_content / verify_claim_against_source。三种用途的输入与输出契约本就不同，一个工具承载三份契约必然导致输出形态不稳。

D3 治标不治本违反 P4A：mode 参数把三个职责塞进一个签名，模型仍要在同一个工具描述里推断该传哪个 mode——选择难度没有降低，只是从「选工具」变成了「选参数」，而参数的语义比工具名更不显眼。「在调用处显式声明用途」听着像契约，实际上那份契约仍然只写在一个工具描述里，下游拿到的依旧是一个可能返回三种形态的工具。

D2 过度工程违反 P4B：union schema 让每个调用方都要处理三种可能的返回形态，把复杂度从工具边界推给了全部下游——与「defined input/output contracts」的方向正好相反。

D3 治标不治本违反 P4D：few-shot 能改善格式一致性（TS 4.2），但这里的根因是一个工具承担三份不同契约这个接口设计问题。示例只能缓解症状，边界仍然模糊。

ch11 · Q6 · 准则 P4

After integrating three MCP servers, your single support agent now has 18 tools available. Tool selection accuracy has dropped noticeably, with the agent sometimes reaching for repository tools during billing conversations. All 18 tools are individually well described. What is the most effective structural change?

正确 BTS 2.3 的两条正面命中：工具过多（guide 举的正是 18 vs 4–5）会因决策复杂度上升而降低选择可靠性；拿到专业外工具的 agent 倾向误用（题干的「billing 对话里去够仓库工具」）。解法是按角色收敛工具集。

D3 治标不治本违反 P4A：题干已说明 18 个工具各自描述良好——问题在数量带来的决策复杂度，不在单个描述质量。继续加描述还会让每次决策要读的内容更多。

D4 甩锅错位违反 P4C：断开服务器会连带失去那些工具提供的真实能力。TS 2.4 的设计前提就是多服务器工具同时可用；控制手段是分配，不是少接。

D1 凭空捏造违反 P4D：tool_choice: "any" 保证模型调用某个工具而不是返回纯文本，它不缩小候选集合，也不提升选对的概率——18 选 1 的难度一点没变。

ch11 · Q7 · 准则 P4

A research system has analyze_content (used by the web search agent on retrieved pages) and analyze_document (used by the document agent on uploaded PDFs). Both are described as "Analyzes content and extracts key information." Agents frequently call the wrong one, and the two produce differently shaped results. What is the appropriate fix?

正确 DTS 2.1 的原例逐字命中：通过重命名工具并更新描述消除功能重叠——guide 给的例子正是 analyze_content → extract_web_results 并配 web 专属描述。名字本身在暗示重叠职责时，光扩写描述不够，要连名字一起改。

D2 过度工程违反 P4A：两者的输入来源与输出形态本就不同（网页 vs PDF），合并会制造一个必须内部分支的泛化工具——正是 TS 2.1 建议拆开的那种形态，方向反了。

D3 治标不治本违反 P4B：scoped 分配是对的做法（TS 2.3），但它只是让当前这两个 agent 碰不到对方的工具；重叠的命名与描述仍然留在系统里，下一个需要同时接触两者的角色会重蹈覆辙。它掩盖问题而非消除问题。

D3 治标不治本违反 P4C：加参数不解决「该调哪个工具」——模型要先选对工具才轮到填参数。而且它把区分信息藏进了参数语义，比放在工具名里更不显眼。