tool.completed不等于业务动作已完成。本文用一个需要确认的写工具说明事件、权限和业务回执的最小接线。在 AI 助手里tool.completed不是“业务动作已完成”的同义词。要让一次创建工单、提交采购申请或发送通知可追溯应用需要把四种事件串起来工具提议、权限决定、工具生命周期和业务系统回执。下面用一个需要用户确认的写工具说明最小接线边界。先定义审计链的四个锚点tool.proposed记录工具名、toolCallId和经过筛选的参数摘要回答模型准备做什么。tool.permission.decided记录allow、deny或ask以及decisionSource它回答为什么放行或拒绝。tool.started、tool.completed、tool.failed记录是否真正进入 handler、耗时和错误类型。业务回执由 handler 调用的业务服务返回businessRequestId、状态和查询入口回答外部系统到底发生了什么。第一到第三项来自运行链第四项必须由业务服务提供。不要用模型最后一句话代替第四项。让权限决定进入自己的审计出口下面是接线示意省略模型客户端、真实业务服务和 UI它展示责任边界不是复制即上线的完整教程constcreateTicketdefineTool({name:create_ticket,description:创建当前用户有权提交的工单,readOnly:false,parameters:{title:{type:string},priority:{type:string}},handler:async(args)ticketService.create({tenantId:auth.tenantId,userId:auth.userId,idempotencyKey:requestContext.idempotencyKey,...args})});constsessionawaitcreateSession({client,tools:{custom:[createTicket]},permission:{rules:{ask:[create_ticket]},askUser:async(call)ui.confirm(call.name)},onDecision:(record)audit.write({...record,userId:auth.userId,tenantId:auth.tenantId})});这里的onDecision只接住权限决定它不能替代业务回执。审计表还应在 handler 开始、结束或失败时补运行状态并在业务服务返回后写入businessRequestId和权威状态。参数是否完整落盘由应用按敏感级别决定不能把令牌、客户资料或完整请求体无条件写进审计日志。权限决定的三种结果不能混成一个布尔值allow表示这次调用通过权限判断deny表示被拒绝ask表示需要确认或进入询问面。没有接入askUser时涉及确认的调用可能按 fail-closed 被拒绝应用应把这个结果显示为“需要确认/策略拒绝”而不是空数据。decisionSource能帮助排查是用户、规则、模式、策略还是钩子做出的决定matchedRule若存在也可以用于管理者复盘。createSessionView适合把这些会话事件投影成工具卡、确认提示和错误状态但它不替应用保存审计数据库。页面要同时显示工具状态和业务状态工具完成后仍要查询业务请求号才能决定显示“已受理”“处理中”还是“结果未知”。超时后先查回执再决定重试业务写工具至少需要一个稳定请求号。调用超时可分成三类尚未提交、已受理但未返回、已经有明确结果。应用先按请求号查询业务系统只有确认未受理且业务接口允许重试时才重新提交。SDK 的会话事件可以帮助你标记运行阶段去重和补偿仍属于业务服务。什么时候采用这条链它适合 Node.js 或 Electron 应用中同时存在多轮任务、需要用户确认的工具和可查询的业务回执。Tansr 可以组织工具、权限和会话事件把决定通过onDecision暴露给应用应用仍负责身份、租户、幂等、审计存储和数据脱敏。一次固定查询或已经具备完整审计链的运行框架不需要为了增加一条事件而迁移。最小验收包括允许、拒绝、等待确认各跑一次确认工具开始和完成事件可见超时后能按业务请求号查到最终状态审计记录不会泄露参数中的敏感字段。完成这些检查后再决定是否扩大写工具范围。接口依据见 Tansr 的PermissionOptions、PermissionRules、会话与事件流和createSession。示意代码省略真实模型和业务服务上线前必须在自己的 Node.js 或 Electron 宿主中验证。