Agent能力边界与降级策略文档化：菜单上先写清“今日供应”

可视化演示

展示AI Agent能力边界三层模型（功能/性能/限制）、四维评估方法（基准/对抗/探测/反馈）和降级策略四阶段流程（正常→检测→降级→恢复）,三模式理解Agent边界文档化要点。

边界定义：先画清厨房的“灶台范围”

后厨的灶台只有四个火眼，一次最多同时炒四道菜。聪明的老板会在开业第一天就告诉厨师长：“凉菜、小炒、蒸菜、炖汤，这四类我们做；分子料理、火焰冰淇淋，一概不接。”这不是认怂，而是让所有人——包括后厨、服务员、采购——对“今天能端出什么”有统一认知。AI 产品的第一步，就是给 Agent 画出同样的“灶台范围”。

在 AI 产品语境里，能力边界指的是 Agent 在给定输入下能可靠完成任务的集合。它不取决于“模型理论上会不会”，而取决于“产品承诺上能不能”。文档化时，通常拆成三张清单：能做什么（白名单，比如“查天气、设提醒、查日程”）、不能做什么（黑名单，比如“不处理支付、不提供医疗建议”）、以及灰色地带（需要人工判定或强制降级的输入）。

边界判定要可测试，才能写进验收标准。产品经理可以用一个集合模型来描述：所有用户请求构成输入空间，能力边界就是其中的一个子集，请求落在子集内正常处理，落在子集外触发降级。

回到餐厅的比喻：菜单上写着“火焰冰淇淋不做”，客人点了这道菜，服务员就能立刻说“抱歉，这道菜我们没有，但可以试试我们的招牌焦糖布丁”。这份从容，来自开业那天就画清楚的“灶台范围”——边界越清晰，应对越从容。

降级策略：招牌菜售罄时的三套接住方案

客人点的招牌菜售罄了，一家体面的餐厅绝不会冷冰冰甩一句“没有”，而是给出三个选择：“要不要试试口味相近的替代菜？或者帮您预订明天最新鲜的一批？实在着急，我们联系隔壁合作餐厅帮您调货。”这三种回应，恰好对应降级策略的三个层级。

降级的本质，不是向用户宣告失败，而是用备选路径承接用户的目标。在 PRD 中，每个能力边界外的请求，都必须能映射到一个降级动作。常见的分级方式是 L1 到 L3：L1 提示引导——告诉用户这个请求超出能力范围，并给出替代指令建议；L2 替代方案——提供等价路径，比如返回人工可操作的模板、官网链接或自助查询入口；L3 人工介入——涉及资金、投诉、医疗等高风险场景，直接转接人工客服或专家，不让 Agent 硬扛。

设计降级策略时，还要考虑数据保全：降级过程中用户已上传的文件、填写的表单不能丢，要随请求一起移交给兜底流程。最后，用降级成功率来检验这套“安全网”是否真的接住了用户。

服务生把“招牌菜售罄”的预案练到极致，客人反而会记住这家店的贴心。降级策略的意义正是如此：能力边界外的每一次“做不到”，都是一次展示产品温度的机会。PRD 里写清三级降级、兜底流程、告知文案和数据保全，就是在为这种温度做彩排。

文档撰写：这份菜谱要连实习生都看得懂

老板头脑里有一本“什么菜能做”的账，但如果不落到纸上，新来的实习生就会在大厨休假时对着点单发呆。PRD 就是那本落到纸上的菜谱——它必须细到让一个从没进过这家厨房的人，也能照单备料、照单出菜。

能力边界文档化，建议采用“四件套”结构化模板。第一件是能力清单：一张表，列出能力名称、触发输入示例、期望输出；第二件是降级策略表：每个边界外场景对应降级等级、兜底动作、用户告知文案；第三件是场景示例法：用“给定输入 → 期望行为 → 降级动作”的三栏格式，写出 10 到 30 个典型场景，覆盖白名单、黑名单和灰区；第四件是验收标准：每一条能力声明都要有可执行的判定方式，比如“对'查天气'类请求，响应成功率不低于 95%”。

边界描述有个常见规范：用用户的话写输入，用系统的话写输出。比如不要写“处理天气类意图”，而要写“当用户说'今天会下雨吗''明天多少度'时，返回对应城市未来 24 小时天气”。文档写没写全，可以用边界覆盖率来量化。

一本好菜谱，不取决于文笔多华丽，而取决于实习生照着做能不能出菜。PRD 的能力边界文档同理——它不需要炫技，需要的是让每个读文档的人，都能复述出“Agent 能做什么、不能做什么、做不到时怎么办”这三个问题的标准答案。

团队协作：后厨、服务员、品控的三方共识

餐厅里最怕的是什么？后厨以为菜单上写了“火焰冰淇淋”，服务员却从没见过这道菜，品控也不知道该按什么标准验收。三方各有一套理解，客人点单时必然鸡飞狗跳。AI 产品的开发、测试、产品团队，也会因为边界文档缺失而陷入同样的混乱。

开发团队的预期对齐，从 PRD 评审就开始了。开发要确认两件事：一是能力清单里的每一项是否在排期内可实现，二是降级策略表的兜底动作是否已有依赖服务（比如转人工需要客服系统工单接口）。如果开发发现某个“能力项”根本无法实现，必须在评审会上提出，而不是等上线后被用户打脸。

测试团队则是边界文档的最大受益者。PRD 里的场景示例表，可以直接翻译成测试用例：每个“能做什么”的白名单场景对应正向用例，每个“不能做什么”的黑名单场景对应反向用例，每个降级策略对应一条“边界外请求 → 验证兜底动作”的专项用例。责任划分也要写清：边界判定逻辑由算法团队负责，降级流程由后端团队负责，用户告知文案由产品经理负责，测试团队对三者做端到端验收。

评审会上，可以用风险值来给每条边界打分，决定优先级。

三方共识的本质，是把“我以为”变成“文档上写着”。后厨按菜谱备料，服务员按菜谱推荐，品控按菜谱验收——当 PRD 里的边界与降级策略成为唯一事实来源，团队协作就从“靠默契”升级为“靠共识”。

期望管理：不承诺满汉全席，只承诺今日供应

一家聪明的餐厅，不会在招牌上写“能做出全世界所有菜”，而会写“今日供应：家常小炒、蒸菜、炖汤”。为什么？因为管理预期比满足预期更重要。用户失望的根源，往往不是能力不足，而是预期与现实的落差。

用户预期管理，第一道防线是产品内的官方说明文档和帮助中心：明确列出 Agent 能处理哪些事项、不能处理哪些事项，用通俗语言而非技术术语。第二道防线是风险提示标注：在关键流程入口（比如即将进入 Agent 能力边界外的操作时）给出提示，“以下操作将转接人工客服，可能需要等待 2 分钟”。第三道防线是客服话术：客服团队要拿到降级策略表的“人话版”，当用户因 Agent 能力不足而投诉时，能用统一口径解释并引导。

这些动作背后的逻辑，可以用一个简单的“满意度公式”来理解——用户的满意度取决于实际体验与预期体验的比值。

菜单上写“今日供应：四道菜”，客人就不会为没有佛跳墙而愤怒；菜单上吹“什么都有”，客人点佛跳墙吃不到，就会给差评。期望管理不是降低产品的雄心，而是把承诺精确到“今天能端出的每一道菜”上。

迭代更新：菜单要随季节换新，但不能悄无声息

夏天的菜单有凉拌菜，冬天就要换成砂锅煲。餐厅换菜单，要提前通知采购、培训厨师、更新价目表，而不是某天客人点菜时才发现“这道菜没了”。Agent 的能力边界也一样，它会随模型升级、数据更新、需求变化而移动——但每次移动，都要走一套正式的变更流程。

边界变更的第一步是更新 PRD 文档：新增的能力要补充到能力清单和场景示例表，移除的能力要标注废弃原因。第二步是版本记录追踪：在文档头部维护变更历史表，记录版本号、变更日期、变更人、变更摘要，让任何成员都能追溯“这个边界是什么时候、为什么改的”。第三步是回归测试验证：新增或收窄边界后，跑一遍全量场景用例，确保旧能力没退化、新能力真可用。

回归测试的通过率，是边界变更能否发布的关键闸门。

换季菜单的每一次更新，都是一次小型的“发布仪式”：更新菜谱、培训后厨、通知服务员、告知老顾客。Agent 的能力边界更新也是如此——文档先变、测试跟上、通知到位、反馈回流。这样循环往复，菜单越写越准，团队越配合越顺。

---

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""Agent 能力边界检查与降级分发演示代码""" class AgentBoundaryChecker:    """把 PRD 中的能力边界与降级策略实现为一个可执行的请求分发器"""     def __init__(self):        # 能力边界白名单: 对应 PRD 中"能做什么"清单        self.scope_list = [            "查询天气",            "设定提醒",            "查询日程",            "发送邮件",        ]        # 降级策略表: 边界外请求按关键词匹配降级等级与兜底动作        self.degrade_map = {            "支付": ("L3", "转接人工客服处理资金问题"),            "投诉": ("L2", "生成投诉工单并跟踪处理"),            "未知": ("L1", "提示用户提供更明确的指令"),        }     def in_scope(self, request):        """判断请求是否在能力边界集合内"""        return request in self.scope_list     def get_degrade_plan(self, request):        """为边界外请求匹配降级方案"""        for keyword, plan in self.degrade_map.items():            if keyword in request:                return plan        return ("L1", "记录反馈并提示稍后重试")     def dispatch(self, request):        """统一分发入口: 能力内执行, 能力外降级"""        if self.in_scope(request):            return {"status": "success", "action": "执行: " + request}        level, fallback = self.get_degrade_plan(request)        return {"status": "degraded", "level": level, "action": fallback}  def main():    """模拟一组用户请求, 观察正常处理与降级分支"""    checker = AgentBoundaryChecker()    requests = ["查询天气", "帮我支付这笔订单", "设定提醒", "我要投诉快递"]    for req in requests:        result = checker.dispatch(req)        print("请求[{}] -> {}".format(req, result))  if __name__ == "__main__":    main()

1. self.scope_list = [...]能力边界白名单，对应 PRD 里“能做什么”表格，这是一切判定的基准
2. self.degrade_map = {...}降级策略表，把边界外请求按关键词映射到 （等级，兜底动作）
3. def in_scope(self, request)边界判定函数，本质就是上文的集合成员判断 $x \in \mathcal{B}$
4. level, fallback = self.get_degrade_plan(request)能力外请求在这里匹配降级方案，返回 L1/L2/L3 等级
5. if __name__ == "__main__":可执行入口，跑起来直接观察四种请求的流向

常见误区

面试题