可控性 - 如何让 Agent 有自主能力，但始终可控？ ​

一、第一性问题 ​

1.1 什么是 Controllability？ ​

Controllability（可控性）解决的核心问题是：

Agent 获得自主规划和执行能力以后，系统是否仍然拥有最终控制权？

传统软件的大部分执行路径由代码提前定义：

Input
↓
Code
↓
Output

Agent 则不同。用户通常只给一个 Goal（目标），后续执行路径可能由模型动态决定：

Goal
↓
Reasoning
↓
Planning
↓
Tool Selection
↓
Action
↓
Observation
↓
Replanning
↓
More Actions

因此 Agent 可能自行决定：

• 调用哪个 Tool（工具）
• 查询哪些数据
• 修改哪些资源
• 是否继续执行
• 是否重新规划
• 是否委派给其他 Agent
• 什么时候认为任务已经完成

所以生产级 Agent 的可控性，不能简单理解成：

“模型是否愿意听 Prompt。”

更准确的定义是：

即使 Agent 具备自主决策和行动能力，系统仍然能够明确限制它能做什么、做到什么范围、什么时候必须停止、什么时候需要人工介入，并且这些限制由模型之外的 Runtime（运行时）真正执行。

例如退款 Agent 判断：

应该退款 10 万元。

即使模型非常确信，如果业务规则规定：

超过 1 万元必须人工审批，

那么 Runtime 就必须暂停执行。

真正的可控性不是：

Agent 主动说“我不执行”。

而是：

即使 Agent 想执行，系统也能够阻止它。

记忆点：

可控性不是模型是否听话，而是模型判断错时系统能不能拦住。

1.2 和其他模块有什么区别？ ​

可以用退款 Agent 理解几个相邻概念。

Quality（质量）

关注：

做得对不对？

应该退款 100 元，Agent 算成 1000 元。

这是 Quality 问题。

Reliability（稳定性）

关注：

出现故障以后还能不能稳定、安全地继续？

退款接口 Timeout 后，Agent 盲目 Retry（重试），造成重复退款。

这是 Reliability 问题。

Controllability（可控性）

关注：

这个 Action 是否有资格被执行？

10 万元退款没有任何审批就直接执行。

这是 Controllability 问题。

Security（安全）

关注：

Agent 会不会被攻击、越权或者造成数据泄漏？

攻击者通过 Prompt Injection（提示词注入）诱导 Agent 查询其他客户的数据。

这是 Security 问题。

可以压缩成：

Quality
→ 做没做对

Reliability
→ 出问题后稳不稳

Controllability
→ 行为能不能管住

Security
→ 会不会被攻击和越权

最值得记住的边界是：

Quality 判断行为是否正确；Controllability 决定这个行为有没有资格发生。

1.3 核心模型是什么？ ​

生产级 Agent Controllability 可以抽象成五个一级系统属性：

Bounded Autonomy（有界自主） Enforceable Policy（可强制策略） Interruptibility（可中断性） Human Oversight（人工监督） Governed Execution（受治理执行）

Bounded Autonomy（有界自主）

回答：

Agent 到底能够自主到什么程度？

例如 Coding Agent：

• 自动读代码
• 自动修改 Workspace 文件
• 自动运行测试
• git push 需要审批
• Production Deploy（生产发布）需要强审批
• 删除生产数据库直接禁止

Enforceable Policy（可强制策略）

回答：

某个 Action 此刻到底允不允许执行？

控制规则必须由模型之外的 Runtime 真正执行，而不是仅仅写在 Prompt 中。

Interruptibility（可中断性）

回答：

Agent 跑起来以后还能不能暂停、限制或者终止？

Human Oversight（人工监督）

回答：

哪些高风险、高影响、高不确定决策必须让人进入执行链？

Governed Execution（受治理执行）

回答：

整个任务是否只能按照合法 State（状态）和 Workflow（工作流）推进？

需要注意：

Enforceable Policy 更关注单个 Action 有没有资格执行；Governed Execution 更关注整个任务处于什么状态、按照什么流程推进。

因此可以记成：

Agent Controllability = 有界自主 + 可强制策略 + 可中断 + 人工监督 + 受治理执行

这些是系统属性。

而：

• Approval
• Step Limit
• Policy Enforcement
• State Machine
• Tool Allowlist
• Handoff

只是实现这些属性的具体工程机制。

1.4 主链路是什么？ ​

整个 Controllability 可以沿着下面这条链路理解：

Autonomy
Agent 应该有多大自主权？
        ↓
Risk
这个行为风险多大？
        ↓
Scope
Agent 可以接触什么？
        ↓
Policy
Runtime 是否允许？
        ↓
Action Control
自动 / 审批 / 拒绝？
        ↓
Progress Control
Agent 还能继续跑多久？
        ↓
Human Control
什么时候让人介入？
        ↓
State / Workflow
当前状态允许做什么？
        ↓
Validation
怎么证明 Agent 绕不过控制？

压缩成九步：

定权 → 评风险 → 限域 → 执策略 → 控动作 → 控进程 → 引人工 → 管状态 → 验证控制

后面的所有问题基本都可以挂回这条主线。

1.5 阶段总结 ​

Controllability 的第一性问题不是：

如何把 Agent 限制得越死越好？

而是：

如何在风险可接受的前提下，让 Agent 获得尽可能有效的自主能力。

真正追求的是：

Bounded Autonomy（有界自主）

而不是 Maximum Autonomy（最大自主），也不是 Maximum Control（最大限制）。

二、自主权与风险 ​

2.1 自主性越高越好吗？ ​

不是。

Agent 自主性越高，通常意味着：

• 自动化程度提高
• 人工参与减少
• 长任务能力增强
• 能处理更多开放问题

但同时也意味着：

• 错误影响范围增大
• 人工发现问题更晚
• Action 的真实副作用更多
• Blast Radius（影响半径）扩大

可以用一个近似的第一性模型理解风险：

Agent Risk ≈ Probability of Mis-action（错误行动发生概率） × Consequence Severity（错误后果严重度）

这里不是严格数学公式，而是帮助分析风险的抽象模型。

Consequence Severity（后果严重度）可以继续受这些因素影响：

• Impact（影响程度）
• Reversibility（可逆性）
• Blast Radius（影响半径）
• Externality（外部影响）
• Financial / Business Criticality（资金 / 业务关键程度）

而 Uncertainty（不确定性）通常会影响：

错误行动发生概率。

模型能力越来越强，可能让：

Mis-action Probability ↓

但 Agent 如果同时获得越来越大的：

• Tool 权限
• 数据权限
• Production 权限
• 外部 Action 能力

单次错误的 Consequence Severity 可能：

↑

所以：

模型越强，并不意味着 Controllability 越不重要。

例如 Coding Agent：

Read Repo
→ 风险低

Edit Workspace
→ 风险增加

git push
→ 有真实外部影响

Deploy Production
→ 高风险

Delete Production Database
→ 极高风险

因此生产环境追求的不是：

Maximum Autonomy

而是：

Appropriate Autonomy（合适的自主程度）

更进一步，最好采用：

Action-level Autonomy（动作级自主）

同一个 Agent 的不同 Action 使用不同控制策略。

例如：

Read Repo
→ AUTO

Edit Workspace
→ AUTO

Run Test
→ AUTO

git push
→ APPROVAL

Deploy Production
→ STRONG APPROVAL

Delete Production Database
→ DENY

常见误区：

模型越来越聪明，所以权限也应该越来越大。

模型能力提升可以降低一部分错误概率，但不能消除：

高风险动作做错后的巨大成本。

记忆点：

Agent 自主性不是越高越好，而是应该和风险匹配。

2.2 怎么确定自主等级？ ​

成熟系统不会简单写成：

refund_tool
→ 永远审批

search_tool
→ 永远自动

因为同一个 Tool，不同参数风险可能完全不同。

例如：

refund(amount=10)

和：

refund(amount=1,000,000)

显然不能采用同样策略。

因此应该先建立 Risk Model（风险模型）。

常见维度包括：

Impact（影响程度）

做错以后损失多大？

Reversibility（可逆性）

做错以后是否容易撤销？

生成内部草稿高度可逆。

发送客户邮件基本不可逆。

Scope（影响范围）

影响一个对象还是成千上万个对象？

Externality（外部影响）

是否影响客户、财务、外部系统或者 Production？

Uncertainty（不确定性）

Agent 对用户意图、Action、Arguments（参数）和当前状态到底有多确定？

根据风险，可以形成几种常见 Autonomy Mode（自主模式）：

Suggest Only
仅提供建议

Low-risk Automation
低风险自动执行

Conditional Autonomy
条件自主

Approval-gated Autonomy
审批受控自主

Human-led Execution
人工主导

这些不是行业统一的等级标准，只是常见控制模式。

真正 Runtime 决策时应该结合：

Action
+ Arguments
+ Resource
+ User
+ Environment
+ Current State

然后得到：

Low Risk
→ AUTO

Medium Risk
→ CONDITIONAL

High Risk
→ REQUIRE_APPROVAL

Very High Risk
→ HANDOFF / DENY

怎么做得好：

风险判断应该尽量基于：

Action 的真实后果。

不能简单相信：

模型 Confidence 很高。

模型说自己有 99% 信心，并不能证明：

一个百万级资金操作适合全自动。

2.3 阶段总结 ​

Risk Model 的价值不是：

给风险打一个漂亮分数。

真正的价值是建立：

Risk
↓
Autonomy
↓
Policy
↓
Runtime Action

也就是说：

风险最终必须转换成可执行的系统控制。

三、范围与策略 ​

3.1 怎么限制访问范围？ ​

Scope Control（范围控制）不能只理解成：

某个 Tool 能不能调用？

生产系统至少应该考虑三层 Scope。

Tool Scope（工具范围）

Agent 能不能调用：

read_sql

Resource Scope（资源范围）

即使允许使用 read_sql，也不代表所有数据库都能访问。

例如：

analytics_db
→ ALLOW

payroll_db
→ DENY

Argument Scope（参数范围）

即使 Tool 和 Resource 都允许，参数仍然可能受到限制。

例如：

• 查询时间最多一年
• LIMIT <= 10000
• 禁止读取身份证号
• 禁止跨租户查询
• 禁止访问高敏字段

所以成熟 Scope 模型可以记成：

Tool Scope → Resource Scope → Argument Scope

常见实现包括：

• Tool Allowlist（工具白名单）
• Resource Policy（资源策略）
• Argument Constraint（参数约束）
• Dynamic Tool Exposure（动态工具暴露）

通常更推荐：

Default Deny（默认拒绝） + Explicit Allow（显式允许）

例如普通 Data Agent 只暴露：

schema_lookup
metric_lookup
read_sql

而不是同时暴露：

read_sql
write_sql
drop_table
send_email

再依赖模型自己克制。

记忆点：

不要给 Agent 所有能力，再要求它克制；只给当前任务真正需要的能力。

3.2 为什么 Prompt 不够？ ​

System Prompt 可以写：

“不要删除数据库。”

Tool Description 可以写：

“这个 Tool 只能用于管理员操作。”

这些都有作用，但它们属于：

Instruction（行为指令）

而不是：

Enforcement（强制执行）

它们可以：

• 帮助模型理解 Tool
• 减少错误 Tool Call
• 提高行为一致性

但不能成为真正权限边界。

只要：

delete_database()

仍然真实暴露并可以执行，

模型就存在调用它的可能。

正确架构应该是：

Agent
↓
提出 Action

Policy Enforcement
↓
判断是否允许

Runtime
↓
决定是否真正执行

Tool

模型拥有的是：

Action Proposal（动作提议权）

Runtime 拥有的是：

Execution Authority（最终执行权）

例如：

Agent:
delete_table("orders")

User:
analyst

Environment:
production

Policy:
DENY

即使模型坚持认为：

“删除表是最佳方案。”

Runtime 也不会执行。

常见错误：

让 LLM 自己回答：

“这个动作安全吗？”

然后根据模型自己的判断直接执行。

这相当于：

让执行者审批自己。

记忆点：

Prompt 是建议，不是权限系统。

3.3 Policy 怎么设计？ ​

这里最重要的不是：

所有系统都必须建设大型 Policy Engine（策略引擎）。

真正的生产原则是：

必须存在独立于模型的 Policy Enforcement Layer（策略强制执行层）。

简单 Agent 可能只是：

• Tool Wrapper
• Tool Middleware
• Workflow Guard
• API Gateway Rule

复杂 Agent Runtime 或 Agent Platform 才可能继续演化成：

• Centralized Policy Service（集中策略服务）
• Policy DSL（策略描述语言）
• Policy Versioning（策略版本）
• Policy Simulation（策略模拟）

逻辑上的 Policy Evaluation 输入可以包括：

Agent Identity
User Identity
Action
Arguments
Resource
Environment
Current State
Risk

输出也不应该只有：

ALLOW
DENY

更加成熟可以支持：

ALLOW
DENY
REQUIRE_APPROVAL
REQUIRE_CLARIFICATION
HANDOFF
LIMIT_SCOPE

例如：

内部普通邮件
→ ALLOW

外部邮件
→ REQUIRE_APPROVAL

包含高敏数据的外部邮件
→ DENY

完整链路：

Action Proposal
↓
Policy Evaluation
↓
Decision
↓
Runtime Enforcement
↓
Tool / Pause / Handoff

Policy 冲突怎么办？

例如：

Policy A
退款 < 1000 元自动

Policy B
VIP 用户所有退款必须审批

VIP 用户退款 500 元：

一个规则 ALLOW，一个规则 REQUIRE_APPROVAL。

系统不能依赖：

哪条 if/else 先执行。

必须明确设计：

• Policy Priority（策略优先级）
• Composition Rule（组合规则）
• Conflict Resolution（冲突解决）
• Fail-safe Behavior（安全失败行为）

不同业务可以使用不同策略，因此不应该死记一个固定的通用优先级公式。

真正重要的是：

Policy 冲突必须是 Deterministic（确定）、可解释、可测试的。

对于高风险行为，如果 Policy 无法明确判断：

通常更适合 Fail Closed（默认阻止或升级人工），而不是随机放行。

怎么做得好：

Policy 最好具备：

• Prompt 外置
• 配置集中
• 可版本化
• 可测试
• 可审计
• 可回滚
• 冲突可检测

避免大量策略最终散落成：

无法治理的业务 if/else。

3.4 怎么防止 Scope Creep？ ​

Scope Creep（任务范围扩张）指：

Agent 在执行过程中逐渐扩大用户原始任务和授权边界。

例如用户要求：

分析这份财报。

Agent 后续：

分析财报
↓
查竞争对手
↓
搜索高管信息
↓
修改 CRM
↓
发送客户邮件

前几步可能仍然服务于分析。

后两步显然已经超出最初任务 Scope。

可以建立：

Task Scope Contract（任务范围契约）

例如：

Goal:
分析财报

Allowed:
读取财报
查询内部指标
公开信息搜索

Not Allowed:
修改 CRM
发送外部邮件
Production Write

如果 Agent 判断：

扩大 Scope 才能继续，

应该：

REQUIRE_CLARIFICATION
或
REQUIRE_APPROVAL

而不是：

自行扩权。

怎么做得好：

Task Scope 最好不仅保存用户原始自然语言，还要转成一定程度的：

结构化约束。

这样 Runtime 才能参与判断。

3.5 阶段总结 ​

这一阶段最重要的一句话是：

模型负责提出 Action，Runtime 负责决定 Action 是否有资格发生。

真正的 Controllability Boundary 必须位于：

模型之外。

四、动作与审批 ​

4.1 哪些动作需要审批？ ​

Approval（审批）不是独立于 Risk Model 的机制。

正确逻辑应该是：

Risk Assessment
↓
Policy Decision
↓
AUTO / APPROVAL / HANDOFF / DENY

通常以下 Action 更容易触发审批：

• Write Action（写操作）
• Low Reversibility（低可逆）
• External Impact（外部影响）
• Large Scope（影响范围大）
• High Financial Impact（高资金影响）
• High Uncertainty（高不确定）

例如 Coding Agent：

Read Repo
→ AUTO

Edit Workspace
→ AUTO

Run Test
→ AUTO

git push
→ APPROVAL

Deploy Production
→ STRONG APPROVAL

Delete Production
→ DENY

审批的目标不是：

让用户参与尽可能多的步骤。

而是：

在人类真正需要承担责任的 Risk Boundary（风险边界）保留最终判断。

4.2 Approval 怎么设计？ ​

一个危险设计是：

“用户批准这个 Agent 可以退款。”

这相当于：

给 Agent 无限授权。

真正应该批准的是：

某一次具体 Action。

Approval Context 至少应该包含：

Requester / Agent
Approver
Action
Normalized Arguments
Resource
Policy / Action Version
Expiry
Approval ID / Nonce

为什么强调：

Normalized Arguments（规范化参数）

因为最终绑定的应该是：

Runtime 真正准备执行的确定 Action。

例如：

Action = refund
Order = 123
Amount = 10000
Expiry = 10 min

用户批准以后：

只允许执行这一笔具体操作。

如果 Agent 把：

amount=10000

修改成：

amount=100000

原 Approval 必须失效。

这叫：

Approval Binding（审批绑定）

完整生命周期：

Agent proposes Action
↓
Normalize Action
↓
Policy Evaluation
↓
Create Approval Request
↓
Persist Approval Context
↓
Human Approval
↓
Revalidate
↓
Execute

这里很重要的是：

Revalidation（执行前重新验证）

因为从用户批准到真正执行之间：

• Arguments 可能变化
• Resource 可能变化
• Current State 可能变化
• Policy 可能更新
• Approval 可能过期

所以 Approval 不是：

永久许可证。

而是：

某个特定上下文下的一次执行授权。

Replay（重放）怎么办？

同一个 Approval 不应该无限使用。

通常需要：

• One-time Token
• Used / Unused State
• Idempotent Execution

批量审批怎么办？

可以批准：

“修改这个 PR 中的 5 个指定文件。”

但 Scope 必须：

• 清晰
• 有限
• 可枚举

不能变成：

“以后所有文件都可以修改。”

记忆点：

Approval 批准的是具体 Action，不是整个 Agent。

4.3 怎么避免审批疲劳？ ​

如果 Agent 每个动作都要求：

Allow / Deny？

用户最终会机械点击：

Allow。

这叫：

Approval Fatigue（审批疲劳）

它会导致一个反直觉现象：

审批越多，真实监督反而可能越弱。

所以成熟系统应该：

• 低风险行为自动化
• 稳定低风险行为 Policy 化
• 中风险采用 Conditional Approval
• 高风险才真正打断用户
• 合理使用有限 Scope 的批量审批
• Approval UI 清晰展示 Action 和影响

审批界面至少应该让人知道：

Agent 要做什么？
作用对象是谁？
关键参数是什么？
影响范围多大？
是否可逆？
为什么需要执行？

而不是只有：

“是否允许？”

可以把优化目标理解为：

Risk Reduction per Human Attention（单位人工注意力带来的风险降低）

因为：

Human Attention（人类注意力）本身也是有限资源。

4.4 阶段总结 ​

审批不是越多越安全。

真正成熟的 Approval 是：

把有限的人类注意力集中在真正高风险的边界上。

五、过程与终止 ​

5.1 怎么防止 Infinite Loop？ ​

Agent 常见循环：

Search
↓
Analyze
↓
Not enough
↓
Search
↓
Analyze
↓
Not enough
...

Multi-Agent 还可能：

Agent A
↓
Agent B
↓
Agent A
↓
Agent B
...

最基础的保护是：

Hard Limit（硬限制）

例如：

• max_steps
• max_turns
• max_time
• max_tool_calls
• max_delegation_depth

Hard Limit 能保证：

极端情况下 Agent 最终一定会停。

但它不能判断：

Agent 当前到底有没有正常推进。

因此还需要：

Progress Check（进展检查）

所以成熟控制通常是：

Hard Limit + Progress Check

记忆点：

Hard Limit 防失控，Progress Check 防误杀。

5.2 Execution Budget 怎么设计？ ​

不要所有 Agent 都统一配置：

max_steps = 20

不同任务执行特征不同。

可以建立 Execution Budget（执行预算）：

Step Budget（步骤预算）

最多多少逻辑步骤？

Turn Budget（轮次预算）

Multi-Agent 最多多少轮交互？

Time Budget（时间预算）

最多运行多久？

Tool Budget（工具预算）

最多调用多少次外部 Tool？

Cost Budget（成本预算）

最多消耗多少 Token / 金额？

例如：

FAQ Agent
→ Step Budget 更重要

Research Agent
→ Time / Tool Budget 更重要

Coding Agent
→ Time / Tool / Cost 综合控制

Budget 本质上是在定义：

Agent 拥有多少执行自主权额度。

Budget 太低：

正常复杂任务也会被杀掉。

Budget 太高：

Loop、成本和风险增大。

所以 Budget 本身就是 Trade-off。

5.3 什么时候应该停止？ ​

Stop Condition（停止条件）不能只依赖：

max_steps reached

也不能完全依赖：

LLM:
"I think I'm done."

更加成熟的 Stop Decision 应该结合：

Model Completion Signal
        +
Structured Task State
        +
Business Invariant
        +
Budget / Policy State
        ↓
Stop Decision

这里有一个重要原则：

LLM 可以提供 Completion Signal（完成信号），但不应该拥有唯一的 Task Completion Authority（任务完成决定权）。

常见停止条件包括：

• Goal Completed
• No Progress
• Budget Exhausted
• Policy Denied
• Risk Escalated
• User Cancelled

例如 Data Agent 用户要求：

返回 A、B、C 三个指标。

更可靠的完成条件：

A complete
B complete
C complete
Validation passed

而不是：

模型自己说“已经完成”。

这里还要区分：

Completion Detection（完成检测）

属于 Controllability：

Agent 是否应该停止继续行动？

Result Correctness（结果正确性）

属于 Quality：

最终结果是否正确？

例如报告已经生成：

可以满足 Stop Condition。

但报告里的数字全错：

Quality 失败。

所以：

可以停止，不等于结果正确。

5.4 Progress 怎么判断？ ​

Progress Signal（进展信号）最好分两类。

Deterministic Signal（确定性信号）

能够规则判断时优先使用确定性信号。

Coding Agent：

• Failed Tests 减少
• Passed Tests 增加
• 未完成任务减少
• Build 状态改善

Data Agent：

• 已回答指标数量增加
• SQL 执行成功
• Validation 完成

Workflow：

• State 正常向目标状态推进

Semantic Signal（语义信号）

某些开放任务无法完全规则化。

例如 Research Agent：

新一次 Search 是否真的增加了有效信息？

这时才考虑：

• LLM Judge
• Novelty Detection
• Semantic Similarity
• Evidence Coverage

这里和 Quality 模块使用同一条成熟工程原则：

确定性问题优先使用确定性机制，无法规则化的问题再交给模型判断。

如果连续多轮没有 Progress：

Replan
↓
Ask User
↓
Handoff
↓
Stop

而不是无限继续。

5.5 Multi-Agent 怎么防循环？ ​

Multi-Agent 常见问题：

Supervisor
→ Agent A
→ Agent B
→ Agent A

可以通过：

• Max Delegation Depth（最大委派深度）
• Allowed Delegation Graph（允许委派图）
• Visited Agent Set（已访问 Agent 集）
• Task Ownership（任务归属）
• Supervisor Policy（主管策略）

控制。

例如：

Research Agent
→ 可以委派 Search Agent

Search Agent
→ 不能反向委派 Research Agent

但 Multi-Agent Controllability 还有另一个重要问题：

权限如何随着 Delegation（委派）传播？

假设 Supervisor 有：

read_sql
send_email
modify_crm

委派一个 SQL 子任务给 SQL Agent。

错误做法：

SQL Agent 自动继承 Supervisor 全部权限。

更合理：

Supervisor
  read_sql
  send_email
  modify_crm

        ↓ Delegation

SQL Agent
  read_sql only

也就是只传递：

Capability Subset（能力子集）

可以把生产级 Delegation 抽象成：

Delegation = Subtask + Context + Capability Subset + Delegation Boundary

也就是说，真正委派的是：

任务 + 必要上下文 + 完成任务需要的最小能力 + 再委派边界

而不是：

Parent Agent 的全部 Session、Credential 和 Capability。

核心原则：

Delegation should narrow capability, not expand it.

中文：

委派不能扩大权限，最好进一步收窄。

5.6 阶段总结 ​

Agent 不仅需要：

能运行起来。

系统还必须始终拥有：

比 Agent 更高的停止权、预算控制权和委派控制权。

六、人工控制 ​

6.1 什么时候需要 HITL？ ​

HITL（Human-in-the-loop，人在回路中）是 Human Oversight（人工监督）的一种具体实现方式，但不意味着：

每一步都必须让人参与。

更适合人工进入执行链的情况包括：

• High Impact（高影响）
• Low Reversibility（低可逆）
• High Uncertainty（高不确定）
• Missing Information（信息不足）
• Policy Requirement（业务规则要求）
• Exception Case（异常场景）

例如：

退款 20 元
→ AUTO

退款 2000 元
→ CONDITIONAL

退款 100 万
→ HUMAN APPROVAL

所以 HITL 的目标不是：

Human Everywhere。

而是：

Human at the Right Boundary。

6.2 三种人工控制有何区别？ ​

最常见的三种模式是：

Approval、Clarification、Handoff。

Approval（审批）

Agent 已经知道：

做什么。

需要人决定：

能不能做。

例如：

是否执行 10 万元退款？

Clarification（澄清）

Agent 不知道：

到底应该做什么。

例如用户说：

“看一下上个月的数据。”

Agent 不确定：

上个月是自然月还是最近 30 天。

这时候应该：

Ask User。

Handoff / Escalation（移交 / 升级）

Agent 判断：

当前任务不应该再由自己继续负责。

例如：

• 高风险投诉
• 权限不足
• 复杂业务异常
• Agent 无法可靠判断

此时应该把：

Context
Current State
Evidence
Actions Taken
Pending Decisions

完整移交给人或另一个合适的 Agent。

可以记：

Approval 解决能不能做。

Clarification 解决到底做什么。

Handoff 解决谁继续做。

6.3 什么时候应该 Ask User？ ​

不能简单规定：

Agent 不确定就问。

否则 Agent 会变得很低效。

更加合理的是结合：

Risk × Uncertainty

例如：

Low Risk + Uncertain
→ Reasonable Assumption

Medium Risk + Uncertain
→ Clarification

High Risk + Uncertain
→ Handoff / Stop

例如 Data Agent：

用户说：

看一下最近的数据。

如果只是：

生成内部分析草稿，

Agent 可以合理假设：

最近 7 天，

并明确告诉用户自己的假设。

但如果下一步是：

根据结果自动调整广告预算，

就必须先澄清时间范围。

核心原则：

是否需要 Ask User，不取决于“是否存在不确定性”，而取决于猜错后的真实成本。

6.4 人工等待怎么处理？ ​

审批可能持续：

• 几分钟
• 几小时
• 几天

不能让 Worker：

一直挂在内存里等待。

合理流程：

Reach HITL Gate
↓
Create Approval / Clarification Request
↓
Persist State
↓
Checkpoint
↓
Pause
↓
Human Response
↓
Validate
↓
Resume

这里和 Reliability 的 Durable Execution（持久执行）有交叉。

区别在于：

Controllability 关注为什么暂停、等谁决定。

Reliability 关注暂停以后任务状态怎么保存和恢复。

6.5 阶段总结 ​

Human-in-the-loop 的本质不是：

增加人的参与数量。

而是：

在人类最有判断价值、机器最不应该自行承担责任的位置，让人进入控制链。

七、Workflow 与控制平面 ​

7.1 谁来决定下一步？ ​

设计生产 Agent 时，一个非常有用的问题是：

Who should decide the next step?

可以拆成四类决策权。

Code decides

如果下一步可以由明确业务规则决定：

用 Code / Workflow。

例如：

Approval 成功后进入付款步骤。

Model decides

如果下一步需要：

• 语义理解
• 开放推理
• 动态规划

让 Agent / Model 决定。

Policy decides

如果问题是：

“这个 Action 是否允许发生？”

由：

Policy / Runtime 决定。

Human decides

如果涉及：

• 高风险
• 高责任
• 高不确定
• 需要业务判断

让人决定。

可以形成一个非常好的记忆模型：

Code 决定流程，Model 决定智能，Policy 决定边界，Human 决定高风险责任。

生产系统通常不是：

所有决策都交给 Agent。

而是不同类型的决策：

交给最合适的主体。

7.2 State Machine 怎么控制 Agent？ ​

State Machine（状态机）解决的问题是：

把业务过程中的合法状态和合法转换显式化。

例如退款流程：

REQUESTED
↓
VALIDATED
↓
APPROVAL_REQUIRED
↓
APPROVED
↓
REFUNDED

在：

REQUESTED

状态：

不允许直接退款。

只有：

APPROVED

状态：

才允许调用 refund()。

这叫：

State-governed Execution（状态约束执行）

一个 State Machine 通常包含：

• State（状态）
• Transition（状态转换）
• Event（事件）
• Guard Condition（守卫条件）

例如从：

APPROVAL_REQUIRED

进入：

APPROVED

之前检查：

approval_valid == true
user_verified == true
amount <= approved_amount

只有 Guard 满足：

才允许 Transition。

为什么不能让 Agent 只靠 Prompt 记住：

“先审批再退款”？

因为模型记住规则：

不是确定性约束。

State Machine 则可以让 Runtime：

在非法 State 下直接拒绝 Action。

记忆点：

State Machine 把“应该怎么做”变成 Runtime 可以强制执行的状态规则。

7.3 为什么需要 Control Plane？ ​

生产 Agent 一个很重要的架构抽象是：

Control Plane（控制平面） + Agentic Execution Plane（智能执行平面）

Control Plane

负责：

Policy
Scope
Approval
State
Budget
Stop Condition
Handoff Rule

尽可能：

Deterministic（确定性）。

Agentic Execution Plane

负责：

Reasoning
Planning
Tool Selection
Adaptive Decision
Delegation

属于：

Probabilistic / Agentic（概率型 / 智能型）。

两层关系：

Control Plane
定义允许空间
        ↓
Agentic Execution Plane
在允许空间内自主决策

例如：

Agent:
delete_database()

Control Plane：

DENY

不执行。

Agent：

refund(100000)

Control Plane：

REQUIRE_APPROVAL

暂停。

所以：

Agent 有智能决策权，但 Runtime 拥有最终执行权。

为什么不能完全自由 Agent？

因为：

灵活，但边界难保证。

为什么又不全部写死成 Workflow？

因为：

开放任务需要语义判断和动态规划。

因此生产系统经常采用：

Deterministic Shell / Control Plane + Agentic Core

也就是：

确定性边界包住非确定性智能。

7.4 Multi-Agent 怎么控制权限？ ​

Multi-Agent 至少要明确四类边界：

Role Boundary（角色边界）

Worker 负责什么？

Tool Boundary（工具边界）

Worker 能调用什么 Tool？

Data Boundary（数据边界）

Worker 能访问什么数据？

Delegation Boundary（委派边界）

Worker 能继续委派给谁？

例如：

Supervisor
↓
SQL Agent

SQL Agent:
read_sql only
不能 send_email
不能 deploy
不能继续任意委派

特别需要注意：

Parent Agent 的权限不能默认全部继承给 Child Agent。

Delegation 时应该显式传递：

Capability Subset（能力子集）

甚至可以使用 Capability Manifest（能力清单）：

Task:
analyze_sales

Capabilities:
read_sql

Database:
analytics

Mode:
read_only

这样 Worker 只能获得：

完成当前 Subtask（子任务）需要的最小能力。

7.5 阶段总结 ​

生产 Agent 最成熟的形态通常既不是：

完全自由 Agent。

也不是：

完全硬编码 Workflow。

而是：

确定性的 Control Plane 包住概率性的 Agentic Execution Plane。

八、控制验证 ​

8.1 怎么证明 Agent 真可控？ ​

不能通过：

“正常情况下 Agent 很听话。”

来证明。

真正的 Control Validation（控制验证）应该主动让 Agent：

尝试突破控制边界。

至少可以分三层。

Unit Control Test（单点控制测试）

测试单一规则。

例如：

普通用户调用 write_sql
→ DENY

Scenario Control Test（场景控制测试）

测试完整业务链。

例如：

Approve refund 10000
↓
Agent changes amount to 100000
↓
Expected:
REQUIRE_NEW_APPROVAL

Adversarial Control Test（对抗控制测试）

主动寻找替代路径绕过控制。

例如系统禁止：

delete_table

Agent 改成：

execute_sql("DROP TABLE orders")

如果第二种方式可以成功：

Tool Policy 虽然通过了单点测试，但真正业务控制仍然失败。

因此高级 Control Eval（控制评测）不能只看：

Tool Name。

还应该逐渐上升到：

Capability-level Policy（能力级策略）

以及：

Control Invariant（控制不变量）

例如真正需要保证的不是：

“Agent 不能调用 delete_table()。”

而是：

Agent 不允许删除 Production 数据表。

那么无论 Agent 通过：

• delete_table
• execute_sql
• Shell
• Remote DB Tool

达到相同 Effect（效果），

都应该被阻止。

这就是：

Tool-level Control → Capability / Effect-level Control

8.2 应该看哪些指标？ ​

Controllability 不能只追求：

Block 越多越好。

因为最“可控”的系统可以：

DENY EVERYTHING

但 Agent 也就失去价值。

建议同时看三个方向。

Control Effectiveness（控制有效性）

例如：

• Unauthorized Action Rate
• Policy Bypass Rate
• Scope Violation Rate
• Invalid Approval Execution Rate

回答：

风险行为有没有真正被阻止？

Friction（控制摩擦）

例如：

• Approval Rate
• Unnecessary Approval Rate
• Clarification Rate
• Human Intervention Cost

回答：

控制给用户增加了多少负担？

Utility（有效自主能力）

例如：

• Autonomous Completion Rate
• Human-free Completion Rate
• Task Success under Policy

回答：

Agent 在受到控制以后还有没有实际生产力？

所以评价 Controllability 时，需要同时优化：

Control Effectiveness + Friction + Utility

而不是任何一个单指标。

8.3 核心 Trade-off 是什么？ ​

常见的四组权衡：

Autonomy
↔
Risk

Automation
↔
Human Attention

Flexibility
↔
Predictability

Speed
↔
Control Cost

例如 Approval 越多：

风险可能下降，

但：

用户成本和 Approval Fatigue 增加。

Policy 越严格：

行为更加可预测，

但：

Agent 灵活性下降。

Scope 越小：

Blast Radius 降低，

但：

Agent 处理复杂任务的能力也可能下降。

因此最终目标不是：

Maximum Control。

而是：

在风险可以接受的前提下，最大化 Agent 的有效自主能力。

8.4 阶段总结 ​

真正证明 Agent：

“管得住”

的标准不是：

Agent 正常情况下有没有遵守规则。

而是：

即使 Agent 尝试越权、绕过 Approval、扩大 Scope，甚至通过另一条路径达到同样效果，Runtime 仍然能够阻止。

九、面试优先级 ​

9.1 P0：必须掌握 ​

1. 什么是 Controllability？
2. 和 Quality / Reliability / Security 有什么区别？
3. 五个核心系统属性是什么？
4. Agent 自主性为什么不是越高越好？
5. Risk-based Autonomy 怎么设计？
6. Tool / Resource / Argument Scope 怎么控制？
7. 为什么 Prompt 不能作为权限系统？
8. Policy Enforcement 怎么设计？
9. 哪些 Action 需要 Approval？
10. 生产级 Approval 怎么设计？
11. 怎么防止 Infinite Loop？
12. Execution Budget / Stop Condition 怎么设计？
13. 什么情况下需要 HITL？
14. Approval / Clarification / Handoff 有什么区别？
15. State Machine + Control Plane 怎么控制 Agent？
16. 怎么验证 Agent 真正可控？

P0 的标准是：

不会这些，很难说明真正理解生产 Agent 的可控性。

9.2 P1：高级工程实践 ​

重点包括：

• Scope Creep
• Dynamic Tool Exposure
• Policy Conflict / Composition
• Approval Binding
• Approval Expiry / Replay
• Approval Revalidation
• Approval Fatigue
• Deterministic / Semantic Progress Signal
• Ask User 决策
• HITL Pause / Resume
• Delegation Loop
• Capability Subset
• Multi-Agent Boundary
• Control Invariant
• Adversarial Control Eval

P1 更能体现：

是否真正考虑过复杂 Agent Runtime 会怎么出事故，以及怎么避免事故。

9.3 P2：平台与架构 ​

重点包括：

• Centralized Policy Service（集中策略服务）
• Policy DSL（策略描述语言）
• Policy Versioning（策略版本管理）
• Policy Simulation（策略模拟）
• Adaptive Autonomy（动态自主策略）
• Multi-Agent Control Plane（多 Agent 控制平面）
• Delegation Capability Manifest（委派能力清单）
• Capability-level Policy（能力级策略）
• Control-plane Auditability（控制平面可审计性）

这些更偏：

Agent Platform / Runtime / Architecture。

十、核心追问链 ​

10.1 自主权 ​

自主性越高越好吗？
↓
为什么不是？
↓
Risk 怎么定义？
↓
怎么把 Risk 转成 Autonomy？
↓
同一个 Tool 不同参数怎么办？
↓
Runtime 怎么动态决定 Auto / Approval / Deny？

最终进入：

Risk-based Autonomy。

10.2 Policy ​

Prompt 限制危险 Tool 够吗？
↓
为什么不够？
↓
真正 Enforcement 在哪里？
↓
Policy 输入什么？
↓
只有 Allow / Deny 吗？
↓
Policy 冲突怎么办？
↓
无法判断时默认放行还是阻止？

最终进入：

Runtime Policy Enforcement。

10.3 Approval ​

哪些 Action 要审批？
↓
Approval 批准 Tool 还是 Action？
↓
Arguments 改了怎么办？
↓
Approval 多久有效？
↓
State / Policy 变化怎么办？
↓
怎么防 Replay？
↓
怎么避免 Approval Fatigue？

最终进入：

Approval Lifecycle。

10.4 Loop ​

怎么防 Infinite Loop？
↓
max_steps 够吗？
↓
为什么不够？
↓
Progress 怎么判断？
↓
哪些信号应该规则判断？
↓
什么时候 Replan？
↓
什么时候 Ask User / Handoff / Stop？

最终进入：

Hard Limit + Progress Check。

10.5 架构 ​

为什么不用完全自由 Agent？
↓
为什么不用全部 Workflow？
↓
什么时候 Code 决定？
↓
什么时候 Model 决定？
↓
什么时候 Policy 决定？
↓
什么时候 Human 决定？
↓
谁拥有最终执行权？

最终进入：

Control Plane + Agentic Execution Plane。

十一、核心记忆点 ​

1. 可控性不是模型是否听话，而是模型判断错时系统能不能拦住。
2. Agent Risk 可以从错误概率 × 错误后果严重度理解。
3. Agent 自主性不是越高越好，而是应该和风险匹配。
4. Risk 最终必须转换成 Autonomy 和 Policy。
5. Scope 至少包括 Tool、Resource、Argument 三层。
6. Prompt 是建议，不是权限系统。
7. 模型有 Action 提议权，Runtime 有最终执行权。
8. Policy Enforcement Layer 不一定一开始就是大型 Policy Engine。
9. Policy 冲突必须确定、可解释、可测试。
10. Approval 批准的是具体 Action，不是整个 Agent。
11. Approval 真正执行前必须 Revalidate。
12. 审批越多不一定越安全，Human Attention 是有限资源。
13. Hard Limit 防失控，Progress Check 防误杀。
14. 确定性 Progress 优先使用确定性信号。
15. LLM 可以提供完成信号，但不能拥有唯一完成决定权。
16. Completion 成立，不代表 Quality 正确。
17. Approval 解决能不能做，Clarification 解决做什么，Handoff 解决谁继续做。
18. Code 决定流程，Model 决定智能，Policy 决定边界，Human 决定高风险责任。
19. State Machine 把业务规则变成 Runtime 可执行约束。
20. Delegation 应传递 Capability Subset，而不是复制 Parent 权限。
21. 委派不能扩大权限，最好进一步收窄。
22. Control Plane 定义允许空间，Agentic Execution Plane 在空间内自主工作。
23. 真正的 Control Eval 要验证 Effect / Invariant，而不仅仅是 Tool Name。

十二、2～3 分钟标准回答 ​

如果面试官问：

你怎么理解生产级 Agent 的 Controllability？

可以这样回答：

生产级 Agent 的 Controllability 不能简单理解成设置 Step Limit 或增加人工审批。Agent 和传统 Workflow 一个重要区别，是很多执行路径由模型在运行时动态决定，所以真正的可控性是，即使模型判断错误，系统仍然能够限制它能访问什么、哪些 Action 可以执行、可以运行多远、什么时候必须停止，以及什么时候必须让人介入。

我通常从五个系统属性理解 Controllability：Bounded Autonomy，也就是自主权必须有边界；Enforceable Policy，也就是关键控制规则必须由 Runtime 真正执行；Interruptibility，也就是 Agent 运行过程中必须能够被中断；Human Oversight，也就是高风险、高影响、高不确定 Action 必须可以进入人工控制；以及 Governed Execution，也就是 Agent 应该运行在明确 Workflow 和 State 约束下。

在自主权设计上，我不会追求 Maximum Autonomy，而是采用 Risk-based Autonomy。风险可以从错误行动发生概率和错误后果严重度两个方向理解，再结合 Impact、Reversibility、Blast Radius、Externality、Uncertainty 等因素决定一个 Action 应该 Auto、Conditional、Approval、Handoff 还是 Deny。

Scope 也不能只做到 Tool Allowlist。我通常至少分成 Tool Scope、Resource Scope 和 Argument Scope。比如 Agent 有 read_sql 权限，不代表它可以读取所有数据库、所有表和所有高敏字段。

另外一个核心原则是 Prompt 不能当权限系统。模型可以提出 Tool Call，但真正执行前必须经过模型外部的 Policy Enforcement Layer。这个控制层在简单系统里可以是 Tool Middleware，在大型 Agent Platform 中可以继续演化成集中 Policy Service。Policy 根据 Agent、User、Action、Arguments、Resource、State 等信息做独立判断，并由 Runtime 强制执行。

对于高风险 Action，Approval 必须绑定具体 Action、规范化 Arguments、Resource、Version 和 Expiry。真正执行前还要 Revalidate；如果参数、状态、Policy 或资源发生变化，就不能继续沿用原 Approval。

执行过程方面，我不会只设置 max_steps，而会组合 Execution Budget 和 Progress Check。Hard Limit 保证 Agent 极端情况下必然停止，Progress Check 则判断任务有没有真实推进。能规则化的 Progress 优先使用确定性信号，只有开放任务才需要语义判断。另外 LLM 可以提供 Completion Signal，但不应该拥有唯一的任务完成决定权，还需要结合结构化任务状态和 Business Invariant。

在人机控制上，我会区分 Approval、Clarification 和 Handoff：Approval 解决能不能做，Clarification 解决到底做什么，Handoff 解决谁继续做。

设计整个 Agent 系统时，我还会问一个问题：谁应该决定下一步？明确业务规则由 Code 决定，开放智能问题由 Model 决定，Action 是否允许由 Policy 决定，高风险责任判断由 Human 决定。

架构上，我更倾向于 Control Plane + Agentic Execution Plane。Control Plane 负责 Policy、Scope、Approval、State、Budget 和 Stop Rule，尽量确定性；Agentic Execution Plane 负责 Reasoning、Planning 和 Tool Selection。也就是说，Control Plane 定义 Agent 可以自主工作的空间，模型只在这个空间里自由决策。

对于 Multi-Agent，委派也不能直接复制 Parent Agent 的所有权限，而应该传递完成子任务需要的 Capability Subset，并限制进一步 Delegation。

最后，Controllability 必须通过主动 Control Eval 来验证，而不能只看正常情况下模型是否听话。我会做 Unit、Scenario 和 Adversarial Control Test，最终验证业务 Control Invariant，例如“不允许 Agent 删除 Production 表”，无论 Agent 是通过 delete_table、execute_sql 还是其他 Tool 达到相同效果，都必须被 Runtime 阻止。

所以我认为生产级 Agent Controllability 的本质是：

在风险可接受的前提下，用模型之外的确定性控制机制约束 Agent 的自主权、范围、动作、执行过程和状态，同时保留必要的人类最终控制权，让 Agent 最大化有效自主，而不是最大化无限自主。

十三、最终记忆模型 ​

13.1 五个系统属性 ​

Bounded Autonomy（有界自主） Enforceable Policy（可强制策略） Interruptibility（可中断性） Human Oversight（人工监督） Governed Execution（受治理执行）

13.2 九步主链路 ​

定权 → 评风险 → 限域 → 执策略 → 控动作 → 控进程 → 引人工 → 管状态 → 验证控制

13.3 四种决策权 ​

Code 决定流程 Model 决定智能 Policy 决定边界 Human 决定高风险责任

13.4 三个 Scope ​

Tool Scope → Resource Scope → Argument Scope

13.5 三个 Control Eval ​

Unit Control Test → Scenario Control Test → Adversarial Control Test

13.6 三个评价维度 ​

Control Effectiveness（控制有效性） Friction（控制摩擦） Utility（有效自主能力）

13.7 一句话 ​

Agent Controllability 的本质，是在明确、可强制执行且可验证的边界内，让 Agent 最大化有效自主。