Coinbase工程团队8月28日介绍了一款内部助手CEEcil。它常驻Slack，在工程师处理事故、查询服务负责人或回顾历史决策时提供帮助。类似工具听起来并不新鲜，真正值得看的却是Coinbase如何处理一个经常被演示忽略的问题：聊天机器人要在团队里长期有用，既要记得过去发生过什么，又不能把所有对话都吞进数据库，更不能因为“乐于助人”而越过权限边界。
CEEcil被团队称为拥有“人类式记忆”的支持同事，但它仍然是一套软件系统。它只进入明确批准、主动加入的Slack频道，不读取私密频道和私信，也不会向前追溯抓取加入之前的历史。这个边界让记忆从一开始就带有范围，而不是先尽量收集数据，再讨论如何删除。对处理客户资产和身份信息的金融平台而言，这比模型是否多答对几个问题更重要。
不追求记住一切，而是把零散对话压缩成可维护知识
CEEcil的记忆流程分为几个层次。后台任务每隔几分钟从允许的频道里提取可长期使用的事实，原始观察只短期保留；夜间的“做梦”任务再把这些片段合并成每个频道的摘要，更新团队、服务和历史决策之间的关系。系统因此不会在每次提问时都重新塞入整段聊天记录，而是读取经过整理的知识。
这些知识以Markdown文件保存并进入Git版本管理。选择听起来朴素，却非常实用：工程师能像审查代码一样查看变更、追溯是谁或什么流程加入了某条记忆，并在发现错误时修改或回退。团队目前使用子字符串搜索，等知识库增长到数百页、简单搜索真正成为瓶颈后，再考虑向量数据库。这个决定避开了常见的过度设计，也降低了排查错误答案时的难度。
处理请求时，CEEcil并不把所有问题都交给昂贵的完整代理。值班表、服务负责人等明确查询优先走API和确定性逻辑；普通知识问题使用检索；只有更难、需要多步分析的任务才调用完整代理。这种分层路由既控制成本和延迟，也减少模型在简单事实问题上自由发挥的空间。一个“今晚谁值班”的问题，如果已有权威接口，就没有必要让语言模型猜答案。
系统使用Go服务负责消息接入、路由、记忆更新、发帖和紧急开关，代理运行时只在需要时介入。每次Slack提及都按无状态方式处理，并读取当下完整线程，以避免旧会话状态污染新问题。主动发言则受到频率限制；如果表现不合适，团队可以快速关闭。所谓“同事感”并不是让机器人随时插话，而是把它的参与约束在团队能够忍受和审计的范围内。
会拒绝比会回答更难，权限设计决定能否长期留在团队里
文章披露了一个很有代表性的选择：团队没有让CEEcil记住可识别客户身份的数据，而是提供经过清理的摘要或只保留内部链接。这个拒绝缩小了功能，却避免把Slack里的敏感内容复制成另一份难以治理的影子数据库。AI工具进入企业后，最大的风险往往不是模型突然做出复杂攻击，而是日常便利让数据被无声复制到越来越多的位置。
记忆本身也可能出错。一段事故讨论中的临时判断，几天后可能被证明不准确；负责人会调整，服务架构会迁移，旧流程会废止。若系统只会累积、不懂更新，它越“有记忆”就越容易给出自信的过时答案。Git记录、按频道摘要和夜间合并提供了修正手段，但仍需要知识所有者、过期规则和人工复核。技术可以保留历史，组织必须决定哪些历史仍然有效。
CEEcil目前是Coinbase内部工程实践，不代表它已经成为面向所有企业的成熟产品。它的效果也高度依赖Coinbase已有的服务目录、值班接口、Slack使用习惯和工程文化。另一家公司照搬同一套架构，如果基础资料不完整、频道权限混乱，可能只会得到一个更会复述混乱信息的机器人。
不过，这项实践给企业AI提供了一个比“再接一个聊天框”更有价值的方向。助手需要明确的数据边界、分层的执行路径、能够被人审查的记忆和随时可用的停止开关。模型只是其中一层，周围的权限、版本控制和确定性接口才决定它是否可信。CEEcil最聪明的地方并非表现得像人，而是工程团队没有假设它天然值得信任。
从这个角度看，企业内部代理的竞争不会只比谁能连接更多应用。真正的门槛是能否在持续工作的同时留下清楚证据：它读过什么、为何给出答案、修改了哪些记忆、什么情况下选择拒绝。Coinbase的方案仍在演进，但它已经把一个关键原则写进架构——长期记忆不是无限收集，主动帮助也不是无限权限。能守住这两条线，AI助手才有机会从短期演示留到下一次真正的生产事故。