1. 项目概述为什么智能体需要“确认门”在上一篇文章里我们聊了聊如何把一个“全能型”的AI智能体拆分成多个“专家型”智能体并通过路由机制让它们各司其职。这个架构跑起来没问题但离一个能放心用在生产环境里的系统还差得远。最核心的问题就是写操作。想象一下这个场景你告诉AI助手“给玛丽创建一个联系人”Claude我们假设用的模型自信满满地调用了create_contact工具下一秒一个名叫“玛丽”、带着一个它自己“推断”出来的邮箱的联系人就出现在你的CRM系统里了。没有确认没有撤销生米煮成熟饭。对于查询读操作这或许可以接受但对于创建、更新、删除写操作这就是一场灾难的序曲。我遇到过两个典型问题促使我设计了这个“确认门”机制。第一是幻觉参数模型可能会“自信地”补全你未提供的信息比如凭空生成一个邮箱。第二是意图模糊用户说“我可能得给约翰记个电话”这到底是一个明确的指令还是他在自言自语专家智能体可分辨不了它看到log_activity工具可用可能就直接用了。因此核心需求浮出水面在任何写操作实际发生之前必须让人类用户看到即将发生什么并给予明确批准。这就是“确认门”要解决的问题——一个拦截写入、询问用户、仅在获得明确批准后才执行的待处理动作系统。它不是一个复杂的队列而是一个简单、健壮、以对话体验为中心的安全网。2. 核心设计原则与架构解析设计这个系统时我遵循了三个核心原则它们直接决定了技术实现和用户体验。2.1 原则一读写分离最小干扰不是所有工具调用都需要确认。我们的工具集里大部分是像search_contacts、get_deal_pipeline这样的读操作。这些操作是幂等的、无副作用的阻塞它们只会让对话变得迟钝和令人沮丧。因此确认门的第一条规则就是仅对写操作要求确认。在代码层面我们明确定义了一个写工具集合而不是依赖命名约定比如所有以“create”或“update”开头的函数。显式声明更安全能避免未来添加新工具时的疏忽。export const WRITE_TOOLS new Set([ “create_contact”, “create_deal”, “create_task”, “log_activity”, ]);当智能体调用工具时会经过一个包装函数executeToolWithConfirmation。这个函数会检查工具名是否在WRITE_TOOLS集合中并且当前对话上下文是否支持确认比如是否在一条有用户的聊天频道中。如果是读操作或者不在确认上下文中则直接执行如果是写操作则触发待处理流程。注意采用Set而非数组进行查找是因为Set.has()操作的时间复杂度是 O(1)在频繁的工具调用拦截检查中性能更好。同时显式集合迫使开发者在添加任何新写工具时都必须深思熟虑这是一种主动的安全设计。2.2 原则二单通道单任务对话友好第二个原则是一个对话通道比如一条Slack线程或一个Telegram聊天在同一时间只能有一个待处理的行动。我们不做行动队列。为什么这完全出于用户体验考虑。在即时聊天场景中对话是线性的、连续的。如果用户说“创建联系人A”然后紧接着又问“B的销售额是多少”智能体可能会先为A生成待确认动作紧接着又为B的查询生成回答。如果我们将动作排队用户界面就会变得混乱“请确认动作1创建A” 用户还没来得及反应系统又提示“请确认动作2查询B”。这非常反直觉。我们的设计是新的写操作会覆盖旧的待处理操作。用户最新的请求才是最重要的。技术上这通过数据库的UPSERT操作ON CONFLICT ... DO UPDATE实现以频道ID为主键确保始终只有一条最新记录。2.3 原则三自动过期避免悬置最后一个原则是待处理动作会过期我们设置了5分钟的有效期。这个时间窗口是精心考虑的它必须足够长让用户能读完确认信息并键入“yes”或“no”同时又必须足够短避免用户离开聊天几个小时回来后不小心确认了一个早已遗忘的请求。过期机制通过数据库查询时过滤expires_at NOW()来实现过期的动作对系统而言如同不存在。后台可以有一个简单的清理任务定期删除过期数据保持表空间整洁。3. 拦截点与待处理动作流的实现细节整个确认门的核心在于智能体工作流中插入了一个轻量级但坚固的拦截点。3.1 工具执行包装器原有的executeTool函数是直接调用CRM API的。我们创建了一个新的executeToolWithConfirmation函数来包装它。这个函数是决策中枢。export async function executeToolWithConfirmation( name: string, input: ToolInput, crm: CrmApiClient, confirmation?: ConfirmationContext, ): Promisestring { // 检查是否为写操作且处于可确认的上下文中 if (confirmation WRITE_TOOLS.has(name)) { // 1. 生成人类可读的描述 const description buildActionDescription(name, input); // 2. 将动作保存为“待处理”状态 await savePendingAction( confirmation.channelId, name, input, confirmation.crmApiKey, description, ); // 3. 返回一个“待确认”状态而非真实结果 return JSON.stringify({ status: “pending_confirmation”, message: This action requires confirmation: ${description}, }); } // 非写操作或无需确认直接执行 return executeTool(name, input, crm); }这里有个精妙之处从智能体的视角看工具调用“成功”了。它得到了一个合法的JSON响应只不过这个响应表示“需要确认”而不是包含CRM数据的实际结果。这很重要因为它让智能体的推理流程可以正常继续由它来组织语言告诉用户发生了什么以及接下来需要做什么。如果直接抛出错误或中断会破坏智能体的对话逻辑。3.2 生成人类可读的描述buildActionDescription函数至关重要。它负责将机器友好的工具调用参数如{name: “Maria Garcia”, email: “mariaacme.com”}转换成人一眼就能看明白的自然语言句子例如“创建联系人 Maria Garcia, mariaacme.com”。好的描述应该清晰、无歧义包含所有关键参数。我通常会提取所有输入字段用一致的格式如“字段值”呈现避免JSON原样输出。3.3 待处理动作的持久化存储待处理动作不能只放在服务器内存里。原因有二1) 服务器可能重启内存数据会丢失2) 在动作被确认或取消前用户可能发送其他消息这些消息可能由不同的服务器实例处理。因此我们必须使用外部持久化存储这里选择了PostgreSQL。表结构大致如下CREATE TABLE pending_actions ( channel_id TEXT PRIMARY KEY, tool_name TEXT NOT NULL, tool_input JSONB NOT NULL, crm_api_key TEXT NOT NULL, -- 用于后续执行 description TEXT NOT NULL, created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(), expires_at TIMESTAMPTZ NOT NULL );保存动作的SQL使用了“一通道一动作”的原则INSERT INTO pending_actions (channel_id, tool_name, tool_input, crm_api_key, description, expires_at) VALUES ($1, $2, $3::jsonb, $4, $5, NOW() INTERVAL ‘5 minutes’) ON CONFLICT (channel_id) DO UPDATE SET tool_name EXCLUDED.tool_name, tool_input EXCLUDED.tool_input, crm_api_key EXCLUDED.crm_api_key, description EXCLUDED.description, created_at NOW(), expires_at NOW() INTERVAL ‘5 minutes’;实操心得将crm_api_key这类敏感信息随动作一起存储时务必确保数据库连接是加密的SSL/TLS并且对静态数据加密有考量。虽然这里为了简化执行逻辑直接存储了在生产环境中更安全的做法是存储一个加密的令牌或引用在执行时再通过安全的密钥管理服务解密。4. 用户确认流程与状态机当用户看到“创建联系人XXX – 回复 yes 确认”的提示后整个系统就进入了一个简单的状态机。消息处理器的逻辑需要优先于常规对话逻辑。4.1 消息处理优先级每次收到用户新消息时处理器的第一步不是交给智能体而是检查该频道是否存在未过期的待处理动作。存在待处理动作首先无论用户回复什么立即删除该待处理动作。这是一个关键的安全设计防止网络重试导致动作被重复执行。删除后再检查用户输入输入是 “yes” 或 “y” (不区分大小写)用之前保存的tool_name,tool_input和crm_api_key真正执行工具调用。将结果返回给用户。输入是 “no” 或 “n”告知用户动作已取消。输入是其他任何内容通知用户之前的待处理动作已因新消息而取消然后将这条新消息作为常规输入交给智能体流程处理。不存在待处理动作消息直接进入常规的智能体处理流程。这个设计的优雅之处在于“优雅中断”。用户不会被锁死在一个确认循环里。如果他们改变主意或者只是想问个新问题直接输入即可系统会自动清理旧状态并响应新请求。4.2 与评估器的集成挑战在上一部分的架构中我们有一个“质量评估器”它会在专家智能体生成回复后判断回复是否真正回答了用户问题如果没有会触发重试。但确认门引入了一个新情况智能体回复“我将为您创建联系人…请确认”这从字面上看并没有“完成”用户的请求联系人还没创建评估器很可能会判定为失败并启动重试导致无限循环。解决方案是打一个“补丁”在专家智能体运行后协调器Orchestrator会检查是否创建了一个新的待处理动作。如果创建了就跳过本次评估。这是一个有针对性的例外处理。如果智能体在处理一个写请求时没有触发确认例如它回复“无法创建因为缺少邮箱”那么评估仍会照常进行。5. 安全与容错面向失败的设计在构建这类系统时必须思考每个组件失败时会发生什么。对于确认门我采取了与质量评估器截然不同的容错策略。质量评估器 (Fail-Open)如果评估器本身崩溃或出错我们让回复通过。宁可要一个质量稍差的回答也比没有回答、让用户干等着强。可用性优先。确认门 (Fail-Closed)如果保存待处理动作savePendingAction的过程中出现任何错误数据库连接失败、写入冲突等整个智能体循环会中止并向用户返回一个明确的错误信息。绝对不允许在未经确认的情况下执行写操作。这种不对称性是刻意的。回复质量是“锦上添花”而数据完整性是“生死攸关”。确认门必须是系统中最可靠的部件之一其失败模式必须是“拒绝执行”从而构成一道安全底线。6. 当前方案的优点与待解难题6.1 取得了哪些成效彻底杜绝误写入这是最大的胜利。无论模型如何幻觉参数如何推断在数据落盘前总有一双人眼把关。这为智能体赋予了处理敏感操作的基本资格。对读操作零干扰9个读工具完全感受不到确认门的存在保持了查询的流畅性和即时性。用户体验只在必要时被打断。灵活的对话流用户不会被“困在”确认流程中可以随时用新指令覆盖旧意图符合自然聊天的习惯。6.2 还有哪些挑战批量操作体验差用户如果说“为我提到的这5个人都创建联系人”当前架构会触发5次独立的工具调用从而产生5个独立的待确认动作。用户需要说5次“yes”。理想的体验应该是合并成一个批量确认“即将创建5个联系人A, B, C, D, E。确认” 这需要智能体层面和确认门层面的协同设计。没有撤销Undo功能确认门能防止错误的写入但无法纠正“正确的写入但后来发现是错的”这种情况。比如用户确认创建了联系人之后发现邮箱拼错了。这超出了确认门的范畴需要更上层的业务流程或CRM本身的功能来支持。幻觉检查仍依赖人工确认门把“发现幻觉”的责任完全交给了用户。对于复杂或专业领域的参数用户也可能无法一眼看出问题。未来可以探索在确认前加入一层AI辅助检查例如用一个快速模型对即将执行的动作生成摘要或风险提示。7. 模式泛化与扩展思考虽然我们是在CRM智能体的上下文中构建了这个确认门但其模式具有高度的通用性。任何具备“动作执行”能力的AI智能体只要其动作会对现实世界或数字资产产生不可逆的影响都应该考虑引入类似的人类确认环节。这个模式可以轻松扩展到其他领域智能家居助手执行“关闭所有窗户并打开空调”前需要确认。电商管理助手执行“将此商品降价50%并全网推广”前需要确认。代码生成助手执行“覆盖写入生产环境配置文件”前需要确认。实现上核心抽象是一个ActionGatekeeper它接收动作上下文对根据预定义的策略哪些动作需确认、如何描述、过期时间等决定是直接执行、转为待确认还是拒绝。当前的实现是硬编码的但可以很容易地改造为可配置的策略引擎。在我自己的实践中引入这个简单的确认门后对智能体的信任度有了质的提升。它从一个可能“乱动”你东西的聪明孩子变成了一个凡事会先请示的可靠助手。这种控制感的转变对于将AI智能体从演示玩具转化为生产工具至关重要。下一步我计划探索如何将这个机制与模型上下文协议MCP更深入地结合并优化批量操作的体验。