本页目录5
这个考点是什么
这个考点关注agentic pipeline里两类“防止关键步骤被跳过”的机制：一是流程强制（workflow gates）——用代码而非提示词，保证某个高风险工具调用之前必须先完成某个前置步骤；二是人工交接（human handoff）——判断在什么决策点应该暂停自动化流程，把控制权和恰当的上下文交给人类。
流程强制的核心思路是：凡是后果不可逆、或涉及资金/权限变更的操作（比如process_refund、close_account、生产数据库的DELETE），不能只靠system prompt里加一句“先做A再做B”或几个few-shot示例来约束模型的调用顺序——这些都是概率性的引导，模型仍有非零概率跳过或乱序调用。
真正能兜底的做法是在代码层设一个programmatic prerequisite（程序化前置条件），阻塞后续工具直到前置工具返回了预期结果（比如verified customer ID），或者用Claude API里的tool_choice强制第一轮只能调用某个特定工具，拿到必要数据后再切回auto让模型自主编排。
人工交接则关注：什么时候应该让agent停下来，把决策权交给人。典型触发点是agent遇到一个它无法自行验证、且一旦执行就无法撤销的动作，或者是高风险场景下模型置信度不足。这和响应延迟、连续工具调用次数之类的运营指标无关——那些是监控信号，不是“该不该交人”的判断依据。
为什么考
这个考点常以“生产日志显示agent在N%的情况下跳过某个前置校验步骤，导致误操作”这种场景出题，考察你能否区分“改进提示词/加few-shot示例”（治标，失败率非零）和“加程序化前置条件”（治本，确定性保证）。
干扰项常见套路：把routing classifier（决定本轮启用哪些工具）包装成顺序强制手段，或者把“模型层确认”“打日志记录意图”“固定延时”包装成安全gate——这些都不构成对高风险操作的真正拦截。
另一类考法是判断“什么时候该交给人”：真正合法的触发条件是不可逆且无法验证的决策点、或高风险判断下置信度不足，而不是延迟、调用次数这类运营指标，也不是用户措辞是否随意。
核心辨析
- 1
程序化前置条件 vs 提示词强化
system prompt加强措辞、加few-shot示例都是概率性引导，模型永远有非零概率违反顺序；一旦后果涉及资金、账户状态等不可逆结果，必须用代码层的programmatic prerequisite（阻塞工具调用直到前置步骤返回验证结果）才能给出确定性保证，这是本考点最核心的辨析轴。
- 2
tool_choice强制 vsauto自由编排当流程要求第一步必须先调用特定工具产出关键数据（比如DOI）时，
tool_choice:{"type":"tool","name":...}能在API层面确定性地锁定这一步，之后再切回tool_choice:"auto"让模型自主决定后续工具顺序；不要试图靠提示词描述“先做X”来替代这个机制。 - 3
routing classifier ≠ 顺序强制
routing classifier解决的是“这一轮该给模型暴露哪些工具”，而不是“同一轮里多个已启用工具该按什么顺序调用”。如果一次请求内前置工具和高风险工具同时可用，分类器完全不能阻止高风险工具先被调用，这是一个常见的偷换概念型干扰项。
- 4
人工交接的合法触发条件
agent到达一个它无法自行验证、且执行后不可逆的决策点，或高风险场景下模型置信度不足，或用户明确要求人工介入——这三类才是判断“该不该停下来交给人”的依据。响应延迟、连续工具调用次数、用户措辞是否随意，都是运营/风格信号，不能作为escalation的判断标准。
- 5
高风险破坏性操作前的三种“伪gate”
模型层面问“你确定吗”仍是非确定性的，可能被prompt injection或模型自身推理绕过；单纯记录intent再放行只是observability（留痕），不是enforcement（拦截）；固定延时（比如等10秒）不校验intent、scope、authorisation中的任何一项。真正的gate是程序化校验这三者、并可选配合dry-run预览影响。
- 6
CLAUDE.md 不是强制机制
把团队规范写进项目级CLAUDE.md能统一约定、便于协作，但它本质上仍是喂给模型的文本，依赖模型自觉遵守，属于概率性引导；如果题目问的是“enforce（强制执行）”，答案应指向settings.json里的PreToolUse等hook这类代码层拦截，而不是CLAUDE.md本身。
反模式对照
用更强的系统提示词或更多few-shot示例来保证高风险操作（退款、销户、删库）的执行顺序
用程序化前置条件（如PreToolUse hook判断）阻塞该工具调用，直到前置步骤返回了验证结果
prompt级引导的失败率非零，生产日志里出现的跳过率就是证据；资金、账户这类不可逆后果不能赌在模型顺从概率上。
把routing classifier（决定本轮启用哪些工具）当成顺序强制的替代手段
顺序问题用工具间的程序化前置门槛单独解决，和“该轮暴露哪些工具”的路由决策分开处理
分类器只控制工具集合，不控制同一请求内已启用工具间的调用先后，两者解决的是不同层面的问题。
高风险破坏性操作前只做模型层面的“你确定吗”确认，或仅记录intent之后就放行
做程序化的intent/scope/authorisation前置校验，并配合dry-run预览影响后再真正执行
模型层确认可被prompt injection或模型自身推理绕过；记录日志只是可观测性，事故发生后才看得到，不构成事前拦截。
把团队协作规范写进项目CLAUDE.md 就当作已经“强制执行”落地
CLAUDE.md 用来沉淀约定，真正的强制关口是settings.json里配置的PreToolUse等hook
CLAUDE.md 仍然依赖模型自觉遵守，和其他提示词类引导一样是概率性的，不具备阻断工具调用的能力。