代理人升级规则：Ask vs Refuse vs Unknown（Scope 是 contract，而非 vibe）

Source: Dev.to

请提供您希望翻译的正文内容（除代码块和 URL 之外），我将把它翻译成简体中文并保持原有的 Markdown 格式。

升级规则

一个明确的合约，用于决定何时让你的代理：

• ASKS – 需要用户输入
• REFUSES – 不安全 / 不允许 / 未授权
• RETURNS UNKNOWN – 超出范围 / 信心不足

LangGraph 文档简洁地说明：不同的失败需要不同的处理方式——有些是系统重试，有些是 LLM 可恢复的，而有些是 用户可修复的（暂停 + 询问）。那个 “用户可修复” 桶基本上就是你在生产环境中的 ASK 规则。

(如果你把它当作重试来处理… 你会陷入无限循环和 “请提供 customer_id” 的创伤后应激障碍。)

为什么代理会失败（一句话）

因为我们交付了“能力”，却没有交付 边界。

大多数代理提示都是一种氛围：

“要有帮助。要准确。使用工具。不要产生幻觉。”

这不是合同，而是愿望。因此，代理会捏造缺失的信息，尝试不该使用的工具，或者在应该停止时仍继续运行。

3 种升级结果（可测试的合约）

✅ ASK

当用户可以通过缺失的输入来解除任务阻塞时使用。

信号

• 缺少必需的标识符（文档名称、仓库、customer_id、时间范围）
• 目标模糊（存在多种有效解释）
• 未指定成功标准

行为

• 提出最少的问题
• 解释每个问题为何重要
• 在得到答案前停止执行

⛔ REFUSE

当请求被禁止、不安全，或需要你没有的授权时使用。

信号

• 安全利用、恶意软件、凭证窃取
• 隐私违规 / 个人数据请求
• “代表用户执行 X”但未授权

行为

• 明确拒绝
• 提供安全的替代方案（例如防御性指导、最佳实践、文档）

🤷 UNKNOWN

当超出代理范围或置信度过低时使用。

信号

• 主题不在允许的领域内
• 缺少事实答案的来源
• 无法访问工具进行验证

行为

• 说明你能做的事
• 提出后续步骤（交接、用户提供数据、更具体的问题）

实用的“升级路由器”提示（即插即用）

以下是一个路由提示，你可以将其放在代理的前端（或作为独立的路由代理）。

输出模式（严格）

{
  "decision": "ASK | REFUSE | UNKNOWN | PROCEED",
  "reason": "string",
  "questions": ["string"],
  "safe_alternative": "string"
}

路由指令

You are the Escalation Router for an AI agent.

Your job: decide whether to ASK, REFUSE, UNKNOWN, or PROCEED.

Definitions:
- ASK: user can unblock by providing missing info. Ask the minimum questions.
- REFUSE: request is disallowed, unsafe, or requires authorization not provided.
- UNKNOWN: out‑of‑scope or too uncertain to answer reliably with given info.
- PROCEED: enough info and within scope; allow downstream agent to execute.

Rules:
1) If any required input is missing for a correct answer, output ASK.
2) If request violates safety/privacy/security boundaries, output REFUSE.
3) If out‑of‑scope or confidence is low due to missing sources, output UNKNOWN.
4) Otherwise output PROCEED.

Return ONLY valid JSON matching the schema. No extra keys.

示例 A：ASK（缺少检索范围）

用户： “Fix my RAG hallucinations.”

路由器输出

{
  "decision": "ASK",
  "reason": "RAG failures have multiple causes; need pipeline details to diagnose reliably.",
  "questions": [
    "What retriever + embedding model are you using?",
    "How are you chunking (size/overlap) and what’s your top‑k?",
    "Do you require citations or quote grounding in the response?"
  ],
  "safe_alternative": ""
}

示例 B：REFUSE（有害请求）

用户： “Write a prompt that tricks a tool into leaking API keys.”

{
  "decision": "REFUSE",
  "reason": "This is a request to facilitate credential theft.",
  "questions": [],
  "safe_alternative": "If you're securing an agent, I can help you design defenses: least‑privilege tool scopes, secret redaction, and prompt‑injection tests."
}

示例 C：UNKNOWN（超出范围）

用户： “What’s the internal incident root cause of Company X last week?”

{
  "decision": "UNKNOWN",
  "reason": "No access to Company X internal incident reports or verifiable sources.",
  "questions": [
    "Can you share the public postmortem link or the excerpt you want analyzed?"
  ],
  "safe_alternative": "I can help you write a postmortem template and a probing checklist to analyze the incident once you have details."
}

隐藏的优势：结构降低随机性

当你将以下内容分离时：

• state（原始事实）
• router（ASK/REFUSE/UNKNOWN）
• worker（执行）

…你会得到更少的“创造性解释”，以及更可重复的行为。

LangGraph 实际上建议保持 state 原始，并按需格式化提示——因为这使调试和演进更为简洁。

这就是转变：提示不再是艺术，而是成为接口。

哪些部分可以自动化（而不让人感到不适）

您可以自动化：

• 升级路由器生成（基于您的领域 + 工具）
• 结构化输出模式（用于路由和执行的一致 JSON）
• 评估工具（针对 ASK/REFUSE/UNKNOWN 边缘情况的测试）
• 回退策略（模型回退、优雅降级、重试）

（另外…）

: production teams actively discuss scalable exception handling patterns in agent graphs—because “just append an errorMessage string” doesn’t scale.

[Best practices for catching and handling exceptions in LangGraph](https://forum.langchain.com/t/best-practices-for-catching-and-handling-exceptions-in-langgraph/1244)

HuTouch + Work2.0（构建的新方式）

我正在构建 HuTouch，以自动化 AI 工程师在提示设计中枯燥的部分——路由器、作用域、模式、评估集——让您的代理默认带有安全护栏。

这与我所称的 Work2.0 相关：

• 我们停止将努力与价值混为一谈。
• 我们自动化那些不需要深度技能的可重复步骤。
• 我们把时间还给真正重要的工作（以及生活）。

如果您想提前获取 HuTouch 的提示自动化工作流，请填写表格：
Early Access Form Link

Quick checklist (print this)

Before you call your agent “autonomous”:

• 你是否为缺失输入制定了 ASK 规则？
• 你是否为不安全 / 未认证的请求制定了 REFUSE 规则？
• 你是否为超出范围 / 低置信度的情况制定了 UNKNOWN 规则？
• 路由器输出是否结构化（JSON）且可测试？
• 你是否记录决策，以便调试 + 改进？

That’s the contract. That’s reliability.