执行引擎：成熟商用产品
推理与工具调用由商用引擎承担，我们不重复造。引擎在架构上可切换，换掉它不需要重写业务逻辑。
定位
我们自研的是哪一层
这条线不卖模型能力。把分工先讲清楚，后面的报价与责任边界才有依据——三层里哪一层出问题，找谁、怎么查，事前就是明确的。
办公 IM 通道：官方 SDK
钉钉、飞书、企业微信各走各自平台的官方 SDK，上面套一层共用适配层，同一套引擎对接三条通道，不为每个平台各做一套。
工程层：我们自研的部分
权限闸门、限时授权与审计台账、心跳看护自愈、跨会话消息账本、多机协同。前两层市面上买得到，这一层买不到——它恰恰是客户真正缺的。
为什么要把这件事讲在最前面：把「我们的 AI 能力」当卖点，你没法验证；把「我们做的是哪一层工程」讲明白，你可以逐条问它拦不拦得住、查不查得到。后者才是能写进合同的东西。
权限
危险操作是怎么被拦住的
智能体要干活就得有权限，给了权限就怕它乱来。解法不是「换个更强的模型」，而是把闸门做成可配置、可留痕、可到期。
接入走出站长连接，员工机器不开公网入站
智能体所在的机器主动向外建立长连接并保持，办公网不需要开放入站端口，也不需要为它做端口映射或反向代理。攻击面比「对外挂一个服务」小一个量级。
正则硬闸先判，命中即拦
用规则直接匹配待执行的命令与调用参数，命中即拦下，不依赖模型自己判断危险与否。硬闸的判定不受对话内容与提示词影响。
提示词软闸复核，把影响范围讲成人话
硬闸放过的高风险动作再由软闸复核一次，并把「它要做什么、会影响到哪些对象」整理成一眼能看懂的说明，而不是丢一段原始命令给你。
在办公 IM 内阻塞等待人回复，超时驳回
待批动作推到你的办公 IM，智能体停在原地等着，不猜、不绕行、不自行降级执行。超时没有人回复即自动驳回，默认取值是「不放行」。
限时授权：硬上限 24 小时，逐笔进只追加台账
同类动作要连着做时，可以授权一段时间内自动放行，硬上限 24 小时，到点自动失效，不支持无限期。授权期内每一次放行都写进只追加的审计台账，到期把「这段时间替你批了什么」汇总回来给你看。
必须写明当前的覆盖范围：硬闸目前只覆盖「删除 / 销毁」与「提权 / 系统级」两类动作。文件读写、修改配置属于放行范围，不会触发人工审批。主动说清这条边界，比含糊说一句「全程有人审」诚实得多——需要把更多动作纳入闸门的，属于项目内可配置的范围，在方案阶段逐条约定、逐条验收。
能力
其余能力，以及每条对应的边界
能力好写，边界难写。下面每一条都配一条它做不到的部分——采购真正要评估的是后者。
办公 IM 内常驻智能体
钉钉、飞书、企业微信三条通道共用一套引擎。同事在群里或单聊里发一句话它就接上，不必再进一个新系统、记一套新账号。
边界：通道能力受各平台官方 SDK 约束。平台没有开放的消息类型与接口，我们做不出来，也不用非官方途径绕过。
跨会话记忆与消息账本
会话状态与消息以只追加方式记录并刷盘落地，进程重启后自动补处理还没答复的消息；答应过的事进承诺台账，防止「答应了却忘了回」。
边界：账本保证的是「消息不丢、承诺不漏」，不保证「答复内容一定对」。内容正确性仍由审批闸与人工复核承担。
执行引擎与账号池热切换
账号与代理池支持热切换，不重启服务；额度接近阈值时先预警并降级处理量，而不是等到用尽直接停摆。
边界：后端目前只预留了与模型无关的接缝，具体适配随项目落地。现阶段不宣称多后端并跑，也不做「换个引擎就能立刻上线」的承诺。
多机协同
多台机器各跑各的认领循环，以共享代码仓的目录布局作为协作协议——谁认领了什么、做到哪一步，都体现为仓库里的目录与文件状态，人可以直接打开看。
边界：已知纯协商式的协同在强依赖场景下不稳定。任务之间存在硬先后关系时，仍需要显式编排，不能只靠各机器自行认领。
智能体自省
定期分析自身的运行日志，找出反复出错的环节，小步修改自己的代码，把修法沉淀下来而不是每次重犯。
边界：改动强制落到专属分支，是否合入、是否生效永远由人决定。没有让它自行上线的通道，这一点不做成可配置项。
审计台账
危险动作的每一次拦截、每一次放行、限时授权期内的每一笔自动放行，都写进只追加的台账，带时间点，可导出交给你的审计口径核对。
边界：台账记录的是智能体侧的动作。目标系统内部由其他途径产生的变更不在这本台账里，需要与该系统自身的日志合并看。
运行
故障是怎么被发现与收敛的
我们不写「零故障」。长期跑的系统一定会出故障，值得看的是它多久被发现、怎么收敛、有没有留下机制。
一段真实的连续运行记录
32 天的连续运行里，看门狗自动自愈重启 113 次。也就是说，绝大多数中断没有升级成需要人介入的事故——它们被机制吃掉了。
同一段时间里，有一次离线约 7 小时没有被及时察觉。我们把它写成了复盘，并补上了心跳看护：从此机器不只报告「进程还活着」，还要按周期证明「它还在正常处理消息」。
把这两个数字并排写出来，是因为买方要评估的从来不是「有没有出过事」，而是「出事之后有没有留下机制」。只报前一个数字的说法，你无法验证。
常驻运行包含哪些机制
- 看门狗监控进程状态，异常退出自动拉起
- 心跳按周期上报，长时间无心跳判为离线并告警
- 消息账本只追加并刷盘，重启后补处理未答复的消息
- 每次自愈、每次放行都进审计日志，可回溯到具体时间点
- 故障写成复盘，机制补丁进下一版，不停在「重启一下好了」
数据
数据怎么处理
四个问题，IT 与采购一定会问。这里直接给答复，不绕。
数据放在哪
私有化部署优先，运行在客户自有环境内，数据不出境。需要访问哪些系统、哪些库表、读还是写，在方案阶段逐条列明，由你确认后才接进来。
谁能接触
生产数据仅由获授权的技术负责人接触，接触人数为 1。产品经理参与需求与流程设计，产品讨论与生产访问分开管理；具体授权范围与审计要求在合作前确认。
留不留
按最小必要原则采集与保留：只留支撑功能与审计所必需的字段，留存期限写进合同，到期删除。与项目无关的数据不采、不留、不备份到别处。
能不能审计
访问留痕，审计日志只追加、可导出。谁在什么时间对什么数据做了什么、哪些危险动作被拦下、哪些被放行、限时授权期内批过什么，都能查到具体条目。
这四条不是话术，是可以逐条写进合同并在验收时核对的条款。数据处理的一般说明另见隐私政策；如果你所在行业另有更严格的数据要求，请在初次沟通时就提出来——不满足的我们会直说，而不是先接下来再想办法。