该让模型决定做什么，还是提前把路径写死？答案取决于任务是有一条可预测的路径，还是有很多依赖上下文的变化。
模型驱动：让模型选择工具
Agent SDK 的核心设计原则：给 Claude 提供工具描述，让它根据上下文选择合适的工具。模型审视当前情况（客户咨询类型、PR 特征、文档格式）然后自主决定调用哪些工具、以什么顺序。
这行得通是因为模型能评估硬编码决策树无法预料的上下文。一个客服 agent 看到一个既涉及账单争议又涉及退货的情况——它调整工具序列来同时处理。一个代码分析 agent 看到 Rust PR 就跳过 Python linter。一个研究协调者意识到话题变化很快，就优先看最新新闻而非学术论文。
决策树：当路径是固定的
硬编码决策树适用于没有任何变化的确定性流程。身份验证必须严格按照 3 步监管序列（姓名 → 出生日期 → 安全问题）——没有例外，没有判断余地，偏离会受到合规处罚。这正是决策树正确的场景：路径是已知的、固定的、法规要求的。
关键问题：是否存在需要判断的歧义？ 如果是 → 模型驱动。如果不是，序列是固定的且偏离有风险 → 决策树。
数据说明问题
硬编码提取（版本 A）和模型驱动提取（版本 B）的对比：
- 标准发票：97% vs 96%——基本持平
- 非标准文档（手写、多语言、非常规格式）：61% vs 89%——模型驱动赢了 28 个百分点
决策树在可预测的情况下和模型驱动表现相当。在硬编码路径无法覆盖变化的非标准情况下就崩了。28 个百分点的差距就是适应性重要的地方。
反模式：对所有输入跑所有东西
硬编码一个固定序列，不管上下文对每个输入都跑全部工具——这是两头都不讨好的做法。对 Rust PR 跑 Python linter 浪费资源。对纯文档改动跑安全扫描器只增加延迟不增加价值。这是非 agentic 的自动化脚本模式——完全无视上下文。
正确的混合
大多数真实系统两种方式都用：
- 决策树用于固定流程：API 认证序列、限流、数据格式校验、监管合规步骤
- 模型驱动用于开放式流程：研究策略、来源评估、代码分析决策、客户问题解决
在设计时就把方法匹配到流程类型。不要让模型在运行时决定用哪种范式——那是提前就能确定的。
从决策树过渡到模型驱动
把一个刚性流水线（lint → test → build → deploy）转换为智能 agent 时，不要一次性全部替换。从一个模型驱动的预分析步骤开始，先检查变更并推荐应该跑哪些步骤，初期加人工审批。这在过渡期提供模型智能的同时维持流水线可靠性。
一句话总结： 有变化和歧义的任务用模型驱动，固定的确定性序列用决策树——数据显示模型驱动在非标准情况下赢了 28 个百分点，正是适应性重要的地方。