一、项目背景

我们服务的这家企业内部系统有二十多套，分散在ERP、WMS、工单、CRM各处，员工日常要在不同系统间跳来跳去完成一个动作——比如"查某个商品的实时库存然后下一张调拨工单"。管理层希望员工能用自然语言直接说一句话就把事办了，而不是在五个系统里翻。我们采用的私有化 AI 底座支持函数调用（function calling），看起来很美，但真正落地时发现一个要命的问题：模型会"自作主张"去触发写操作，比如没确认就把库存状态改了、把工单派给错了人。这种误触发在生产系统里是不可接受的，所以我们把"安全"放在"智能"前面来设计。

二、落地场景

我们把每个可调用能力都定义成带权限声明的函数：读类函数（查库存、查订单）默认放行，写类函数（改状态、下工单、派单）必须显式声明所需权限。员工说"把这批货的状态改成已质检"，模型先识别出要调用的函数和参数，系统弹出确认卡，展示"即将执行：将工单 WO-xxxx 状态由待检改为已质检，操作人=你"，员工点确认才真正写库。所有写操作全程审计，记录谁、在什么会话、基于哪句话、改了什么。如果调用失败或参数非法，系统自动尝试回滚到调用前快照，不让半截状态留在库里。

三、关键技术挑战与解决思路

第一个挑战是函数定义的粒度。定义太粗，一个函数干太多事，权限不好控；太细，模型容易乱序拼装。我们的经验是"一个函数一个原子动作"，并把业务约束写进函数描述（比如"下工单前必须先有有效的采购单号"），让模型在调用前就能自我校验。第二个挑战是防误触。我们给所有写函数加了"二次确认 + 风险分级"：高风险操作（状态变更、资金相关）强制人工确认，低风险（如备注补充）可静默执行。第三个挑战是失败回滚。大模型调用常常"调了一半"——比如连续调用里第二个失败，第一个已经写了。我们引入调用事务快照：进入多步调用前先对涉及的主数据做快照，任一步失败则整体回滚并提示，保证业务状态一致。

案例片段（已脱敏）： 一次多步调用的回滚——用户说"把订单 SO-88231 标记为已发货，并生成物流单"。系统先快照订单状态（原=待发货），第一步改状态成功，第二步调物流接口超时失败。触发器检测到第二步异常，自动回滚订单状态到"待发货"并提示"物流单生成失败，已撤销发货标记，请重试"。避免了"状态已改但无物流单"的悬空订单。 权限声明片段：func "update_workorder_status": required_role=["warehouse_lead"], risk_level="high", need_confirm=true, pre_condition="workorder.exists(order_id)"。上线后写类误触发率从灰度初期的约 2.1% 降到约 0.15%。

四、效果数据

内测两个月，覆盖约八个业务动作，函数调用整体成功率从约 86% 提升到约 95%。写类操作的误触发率（未经确认直接改了状态）从灰度初期的约 2.1% 降到约 0.15%，确认拦截拦截掉了所有不应执行的高风险动作。回滚机制在接口异常时成功兜住了约 100% 的半截状态。员工完成同类任务的端到端耗时从平均约 6 分钟降到约 1.5 分钟。数据为脱敏示意口径。

五、可复用经验总结

第一，函数调用落地第一条铁律：写操作必须确认，不能信模型"我以为你要"。第二，函数粒度要原子化，业务约束写进描述让模型自校验。第三，多步调用要有事务快照，否则状态会乱。第四，审计不是可选项，生产系统的每一次写都要能复盘。这套"权限声明 + 风险分级确认 + 调用事务回滚"的框架，后来成了我们所有 Agent 接业务系统的标准安全底座。

附：工程落地细节

函数声明的权限模型我们做成了中心化注册表，每个函数除了参数 schema，还要声明 required_role、risk_level、need_confirm、pre_condition 四个字段，网关在调度前统一校验，新增一个写函数不用改调用逻辑，只改注册表。多步调用的快照我们存在调用会话的上下文里，进入写序列前对涉及的主数据做浅拷贝快照，任一步抛异常就整体回滚并提示，保证业务状态不悬空。审计日志把"用户原话、解析出的函数与参数、执行结果"三者绑定存储，事后复盘能完整还原一次写操作的前因后果。

附：给同行的一点提醒

函数调用落地的第一条铁律是写操作必须确认，不能信模型自以为你要，我们灰度初期就因为一处高风险函数忘了标 need_confirm 吃过一次误改状态的亏。函数粒度要原子化，一个函数干一件事，业务约束写进描述让模型自校验，粗粒度函数权限根本控不住。最后，生产系统接大模型，审计不是可选项，每一次写都要能复盘，否则出问题连责任人都不知道。

附：一点落地后的量化补充

我们给每个写函数都配了"影响面评估"，低风险动作（如补充备注）静默执行、中风险（如改派单）做轻确认、高风险（如状态变更、资金相关）强制二次确认并留痕。灰度期间统计过，确认拦截掉的写操作中约九成确实是模型误判或参数不全，只有一成是用户临时改主意，说明这道确认闸真实拦住了大部分风险。回滚机制上线后，多步调用里任一步失败的恢复时间从人工介入的十几分钟缩到秒级自动完成。