来源：抖音 @Alex的AI进化论

从“0”开始搭建一个工单客服（4）

核心逻辑：工具权限边界与 SOP 的协同

构建工单客服系统的核心是建立工具权限边界管理。这套机制明确每个工具在何种场景下可被调用、以何种方式执行，以及需要哪些前置审批或风险控制措施。

系统用工具请求（Tool Requests）和状态流转定义操作层级：只读查询、资金退款、跨部门数据导出等，每个层级都有对应的权限控制和安全策略。

权限分类与自动化策略

系统按风险程度对工具权限分类，低风险操作自动发送，高风险操作人工审核。

1. 低风险操作的自动执行

风险较低且符合标准作业程序（SOP）的操作由系统自动发送，包括：

• 客户资料查询：仅用于查看客户基础资料，不修改业务状态。
• 回复客户草稿：在低风险的对话场景中，AI 可以自动生成回复草稿，甚至直接发送。
• 记录日志：简单的操作记录，不涉及核心业务变更。

这些操作带 auto_send 或 draft_only 标记。系统在上下文状态为“允许发送”时直接执行，不需要人工干预。

2. 高风险操作的强制审批

涉及资金安全、法律合规或核心数据变动的操作必须人工审批，例如：

• 退款与补偿：任何涉及资金退赔的请求，如 issue_refund_or_compensation，必须进入审批流，确保每一笔支出都有据可查。
• 跨部门数据导出：导出其他部门的数据（如 export_cross_customer_data）属于高危行为，不仅需要审批，还需记录审计日志，防止数据泄露。
• 关闭 SLA 投诉工单：改变工单的最终状态，特别是涉及责任认定的关闭操作，必须由人工确认，避免推诿或误判。

这些操作标记为 forbidden，或需 security 标签才能触发。系统执行前做边界检查，违规尝试会被拦截并提示原因。

技术实现：状态机与边界检查

代码层用状态机（State Machine）和边界检查函数实现。每个工具请求带 ticket_id 和 tool_name，系统据此加载对应 SOP 策略和边界结果。

关键的处理流程如下：

1. 加载上下文：获取当前工单路径、SOP 策略和边界检查结果。
2. 分类工具请求：判断该工具在当前状态是否可用。不可用则返回 forbidden 状态和具体原因。
3. 检查边界上下文：验证操作是否符合边界规则。比如某些操作仅在特定状态下可执行，或需要满足安全信号（risk_signal）。
4. 决定最终动作：根据权限标签（permission_labels）决定自动发送、生成草稿或拒绝执行。

权限标签和 SOP 规则的组合支持复杂业务场景下的细粒度控制。

总结：工具权限边界与业务规范

传统 API 列表只列出可调用接口，不涉及业务上下文和操作后果。本方案把工具定义为权限边界，每个工具的使用对应明确的责任、风险和操作流程。

readonly、draft_only、auto_send 等标签把技术能力转化为业务规范：只读、仅草稿、自动发送分别对应不同级别的操作自由度，数据安全和业务合规由这些标签直接保证。

延伸

以下为编辑延伸解读，非原素材内容。

为什么“工具即边界”比“API 列表”更先进？

在传统的应用开发中，我们习惯于通过 API 网关来控制访问权限。然而，在 AI Agent 或智能客服系统中，仅仅控制“谁能调用接口”已经不够了。因为 AI 可能会基于上下文自主决定调用哪个接口，以及调用的时机和参数。

“工具即边界”的理念，实际上是将业务规则内嵌到了工具的定义中。它不再是一个静态的白名单，而是一个动态的策略引擎。这使得系统能够适应更复杂的业务变化，比如在不同地区、不同客户等级下，同一项操作可能面临不同的审批要求。

潜在挑战与思考

尽管这套机制非常完善，但在实际落地中也面临一些挑战：

• SOP 的动态更新：当业务规则发生变化时，如何快速更新 SOP 策略而不影响线上服务的稳定性？是否需要引入版本管理机制？
• 误判的处理：AI 对上下文的理解可能存在偏差，导致本应自动执行的操作被错误地拦截。是否有申诉或重试机制？
• 性能开销：每次工具调用都需要进行复杂的边界检查和策略匹配，这在高并发场景下是否会成为瓶颈？

这些问题值得在实际工程实践中进一步探索和优化。