公司里的 AI终于不只会聊天我用 GPT‑6 把企业工作伙伴开源了这件事让我彻底改变了对企业 AI 的看法。我们最初做了一个聊天机器人以为能问答、能查资料就够了结果员工根本不爱用。后来我们基于 GPT‑6 级别的大模型能力把原先的机器人重构成一个真正能干活的企业工作伙伴并在内部验证了八个月之后把核心框架开源了出去。这中间踩过非常多坑也沉淀了不少可复用的方法论。这篇文章想跟你聊聊我为什么决定开源、底层架构怎么设计、哪些功能场景最难、以及实际落地时最容易踩的坑。如果你也在公司里搞 AI 助手或者 Agent我相信这些内容能帮你少走很多弯路。1. 从聊天机器人到工作伙伴为什么我决定把内部 AI 工具开源1.1 内部 AI 的演进从问一句答一句到主动帮你干完我们团队最初做的 AI 助手是从内部通讯软件里的一个机器人开始的。当时它的能力很简单员工在对话框里问 年假还剩几天 会议室怎么预约机器人去查对应的表格把结果返回给提问者。这个版本推了将近一年日活始终上不去。大家的反馈出奇一致答案我知道去哪查不用问机器人。 这句话挺打击人但也让我意识到一个关键问题企业内部做 AI最不缺的就是信息获取最缺的是把事办完。员工真正需要的不是被告知报销单填到第几栏而是 AI 直接把报销单草稿填好让他扫一眼确认后提交。但这个需求在早期模型上完全实现不了因为这不是简单的问答或检索而是一连串的动作读文件、理解字段、调用系统、生成草稿、等待确认。真正的转折出现在 GPT‑6 这类具备复杂任务规划能力的大模型落地之后我们终于能做以前做不了的事——多步任务规划。模型不再只是把用户的话转成一条 SQL 或者一次文档检索而是能理解帮我订一个下周二和财务对账的会议室并通知参与人这句话背后其实需要三个连续动作查大家的日程、预定空闲会议室、给参与者发会议邀请。于是我们重新设计了产品定位从问路员升级为跑腿员。这个跑腿员在内部有一个代号叫作 E-Buddy后来也成了开源项目的名字。与聊天机器人最本质的区别是E-Buddy 从只读变成了可写从被动响应变成了主动推进。它开始能在受控范围内替员工做一些影响实际业务的操作比如创建会议、生成草稿、发起申请。每一步操作都记录在审计日志里出了问题可以回溯。这个从 Chat 到 Act的跨越才是企业 AI 工作伙伴的真正分水岭。1.2 开源范围与边界哪些能放出去哪些必须留在内网做到第八个月内部验证效果已经比较明确很多团队都在用。这时团队面临两个选择继续闷头做内部项目还是把框架开源。最终我们选择开源原因有三个。第一企业级 AI Agent 的通用问题比如工具协议、记忆管理、权限校验、审计追踪这些在每家公司里都会遇到但每家都在从零造轮子浪费大量人力。第二E-Buddy 的核心代码并没有绑定任何内部系统我们只是通过适配器去对接不同的办公套件完全有条件抽出通用部分。第三开源倒逼我们把架构做干净把不该出现在日志里的敏感信息清理掉这本身就是一次很好的安全体检。开源与闭源的分界线我们划得比较清楚模块功能是否开源原因Agent 编排引擎意图识别、任务拆解、工具调用序列是通用与具体企业无关工具协议定义工具输入输出的 JSON Schema是通用标准记忆管理器三级记忆的读写与过期是不含业务数据前端对话组件聊天窗口、操作卡片、确认按钮是通用 UI企业连接器对接身份目录、审批流、财务系统否强绑定内网且含密级信息报表与审计后台展示操作日志、用量、成本部分只提供框架不提供企业部署数据安全是这里最敏感的一根弦。我们只开源了框架和示例协议所有接入真实业务系统的适配器都以插件形式留在闭源仓库。这样外部使用者拿到的是一套可以运行在本地模拟数据上的完整系统一旦要接自己的系统再写对应适配层就行。这也是我个人非常推荐的做法不要把真实的系统连接器打包进开源代码否则等于把你们公司的内部接口暴露给了所有人。2. 企业工作伙伴的核心架构角色编排比模型大小更重要2.1 三层架构对话层、调度层、工具层很多人以为企业 AI 工作伙伴就是把大模型接到内部聊天软件里然后让模型自由发挥。我们做下来最大的教训是企业内部 AI 的稳定性不是靠模型足够聪明而是靠系统结构足够克制。E-Buddy 整体分成了三层每一层职责单一边界明确。对话层负责和员工自然交流。它接收消息解析出用户当前意图和关键参数比如时间、地点、金额。对话层不直接调用业务系统它把所有工具调用的结果转成一段简明的人话输出给用户。这一层的输出要审慎不能太啰嗦也不能过于AI 味。我们内部有一条硬规矩一切回复尽量在 50 个字以内除非用户明确要求详细说明。调度层是全系统的核心。它接收对话层传来的、格式化之后的意图结合工作记忆和长期档案决定要完成这个任务需要调用哪些工具、按什么顺序调用、哪些地方需要用户确认。调度层同时维护一个任务状态机比如报销任务可能有填单草稿 → 补充材料 → 用户确认 → 提交 → 跟踪审批状态几个状态。模型在状态之间做决策但状态集合和可行动作是预先定义好的不是模型临时发挥。工具层则是一堆独立的小服务每一个都遵循统一协议。工具层不感知对话历史只负责执行一个具体动作并返回结构化结果。例如查询空闲会议室工具接收时间范围和参会人数返回候选列表创建会议邀请工具接收会议标题、参会人列表和时间返回创建结果以及生成的邀请链接。为什么这样拆分因为在实际业务中模型直接决定调用工具的全过程非常容易出问题。尤其是需要连续几步操作的场景比如把会议时间从周二改成周四模型可能忘了同步给所有参会人。所以我们采用规则加模型的混合方式调度层先用规则打分从几十个工具里筛出几个最合理的候选再由模型从中做最终决定。这样既能利用模型的语义理解能力又能保证候选集不会跑偏。你可以把它理解成一个有经验的行政助理先凭经验把你大概率需要的几份材料摆在桌上再让你自己确认到底用哪份。2.2 记忆管理短期上下文、工作记忆、长期档案企业场景里的多轮对话比普通聊天复杂得多。员工常常上午问帮我看看周五下午谁有档期下午又回来说改成周四吧。如果 AI 只记得对话框最近几条消息完全无法理解改指的是什么。为此我们建立了三级记忆。短期上下文保存当前对话窗口的原始消息和摘要供模型即时推理。工作记忆保存尚未完成的任务草稿例如报销单当前填到了哪一步、预定会议的时间是否已被某个参与者拒绝。这个过程跨多个对话轮次持续存在像一个进行中的工作底稿。长期档案保存员工在授权范围内的固定偏好和权限信息比如常用出差城市、审批权限层级、经费项目编号。长期档案不是后台偷偷抓取而是员工在初始化时主动授权写入的。记忆管理的安全问题我们特别在意。每一项写入都要带上数据来源、授权范围和过期时间并且不能把敏感字段放进模型上下文。开源版本的记忆管理器支持自定义加密存储落地时通常替换成企业内部的加密服务和密钥体系。透明和可控是这件事能做下去的底线。一个典型的工具协议我们定义为长这样{ tool: schedule_meeting, schema_version: 1.2, input: { title: 季度财务对账, duration_minutes: 60, attendee_ids: [user:zhangsan, user:lisi], preferred_start: 2025-06-05T13:00:0008:00, must_confirm: [time_conflict] }, permission: { required_scope: calendar:write, inherited_from: context.employee.permissions } }所有工具都返回统一信封结构{ ok: true, data: { meeting_id: mt_20250605_001, invite_url: https://internal.cal/... }, trace_id: 15f2ab9c }调度层通过trace_id把每一步操作串联起来后续做审计、排障都非常方便。市面上很多 Agent 框架喜欢在代码里到处判断返回结构而我们用统一信封把这个复杂度彻底消灭了。3. 关键功能拆解日程、报销、知识库哪一个最让人头疼3.1 日程管理从帮我查明天有什么会到帮我协调一个会议日程是所有企业 AI 工作伙伴里最容易被小看、但实际最容易翻车的功能。查日程是只读操作模型只要准确读出时间戳就行。但协调会议意味着 AI 要替你做决策比如帮几个人找共同空档这就难多了。我们并没有让模型去凭空想象一个合适时间而是实现了一个独立的时间块评分器。流程是工具层把候选人的日程拉下来调度层把未来五个工作日内每个 30 分钟的时间块切出来再根据三个维度打分忙闲程度、时区匹配、参会者的个人偏好偏好。得分最高的一组时间进入下一步通过对话层向用户推荐并附上使用这个时间或换一组候选的选项。下面是模拟数据的输出样式候选时间段平均忙碌度时区匹配推荐分数周四 14:00 - 15:0012%全部匹配96周五 10:00 - 11:0035%一人需调整84周二 16:00 - 17:0025%一人出差78分数最高的周四下午被推荐用户点击确认后工具层调用日历服务创建会议邀请并通知所有参会人。如果确认过程中有人日程冲突调度层会重新评分给出新的候选。这个过程全程不用人工干预。实际落地中最麻烦的是不同日历服务之间的事件同步协议时区字段格式完全不统一我们做适配层时花了大量时间在这上面。如果你也要接多个日历源建议先抽象出一个统一的事件数据模型再慢慢填不同源的适配器。3.2 报销单员工最烦的场景也是 AI 最容易翻车的地方报销是我们排查事故最多的场景也是员工最有痛感的场景。一个人拿着打车发票、高铁票和饭票对着报销系统里那一堆费用类别本来就烦躁。AI 要做的是不是让员工更烦躁而是把工作尽可能做完再让员工确认。我们的流程是员工上传发票照片或者直接发一段文字比如上周去某客户公司谈完项目打车回公司车费 58 元。工具层先做 OCR再做票据验真然后进入报销规则引擎。规则引擎不是模型而是一堆可配置的条件比如同一笔行程费用不得超过 X 元打车时间必须在工作时段发票抬头必须是公司全称。规则引擎预填报销单但所有涉及金额的项目都标注为待确认。这里有一个极其重要的经验报销、付款、审批这类涉及钱和权限的操作AI 永远只能给出草稿或预填单绝对不能自动提交。我们一开始尝试过让 AI 直接替员工提交报销单结果连续出现两次填错项目编号、选错成本中心的情况。虽然可以改但员工对 AI 的信任度直接掉了一大截。后来改成确认后提交模式提交前对话层用一句话总结已按你的行程预填一笔 58 元交通费成本中心 813需要现在提交吗用户点了确认AI 才执行提交动作。开源版本里保留了确认后执行这个设计模式。如果你拿到代码后想增加自动提交功能我劝你三思。单个人一次误操作问题不大一旦形成路径依赖批量出错是早晚的事。3.3 知识库问答最后发现最值钱的是回答之后的行动链接知识库问答看起来最像传统聊天机器人但它隐藏着我们项目里用户满意度最高的一项设计回答完问题之后AI 会判断能否直接触发一个操作。举例来说员工问公司新桌采购申请流程是什么普通机器人会甩一篇长文让人自己去读。E-Buddy 会先给出三步摘要然后在下面挂一个操作卡片我已了解你的申请范围需要我帮你生成一份申请草稿吗用户点一下AI 转头就把申请单预填好了。实现上我们把知识文档做了分块和向量化同时给每个文档块挂上元数据和关联工具标签。检索命中后调度层不只返回文本而是把命中文档与工具做映射。如果一个文档解释了打印机使用方法检索命中之后会附带联系 IT 维修这件事的入口。这种知识 行动的绑定关系在开源项目里通过一个简单的配置文件实现接入方只要写好文档块的 action 字段就能复刻这种体验。下表对比了三个功能在实际验证中的差异功能使用频率风险等级自动化程度最让人头疼的点日程协调高中高多种日历服务的时区与冲突处理报销预填中高中票据验真和涉及钱的确认知识库问答高低中文档更新后没有即时重索引如果你也想做一个企业 AI 助手我建议先挑日程和知识库这两个风险相对低、见效快的场景做起报销等功能放到第二个迭代再说。先让员工感受到AI 能帮我省时间后面推广复杂功能才有人愿意尝试。4. 开源清单与落地实践别人可以直接复用的部分4.1 仓库结构与最小模块说明开源后的仓库结构大概长这样ebuddy/ ├── agent_core/ # 调度层任务路由、状态机、确认流程 ├── memory/ # 三级记忆管理器含加密接口 ├── tools/ # 工具框架和示例工具 │ ├── calendar_demo/ # 日程查询/占位工具本地模拟数据 │ ├── doc_search/ # 知识库检索工具基于本地向量库 │ └── expense_demo/ # 报销预填工具只出草稿 ├── ui_component/ # 对话组件、确认卡片、操作按钮 ├── adapters/ # 企业系统适配器的接口定义 └── examples/ # 一个可运行的内部协作 Demo核心亮点在agent_core它不到两千行代码把企业里最常用的四条工作流全实现了查信息、提交申请、协调资源、报销预填。我们刻意没有用很重的框架所有任务都可以用一段配置加少量代码描述。tools/目录里的示例工具全部用本地模拟数据不依赖任何外部服务拿到代码后可以直接跑起来。真正的企业连接器没有开源但adapters/目录里定义了标准接口照着实现就能对接自己的系统。如果你想在代码层面看看确认后执行是怎么做的agent_core里有一个独立的 confirm 模块它会拦截所有标记为high_risk的工具调用必须等到用户确认信号才会放行到执行阶段。4.2 快速启动半小时跑通一个最小 Agent在开源仓库根目录只需要三步git clone https://example.invalid/ebuddy.git cd ebuddy pip install -r requirements.txt然后配置config.yaml把模型服务地址填成你们自己用的 LLM API 网关启动 Demo 服务python demo_server.py --config config.yaml如果一切正常你会在本地看到一个带聊天界面的页面。输入帮我查一下明天的空闲会议室它会调起本地模拟的会议室服务返回几个可行时间段。整个过程大概半小时不涉及任何真实业务系统目的是让你先理解分层调度的运行路径。需要重点说明的是config.yaml里有三个参数决定了企业环境的适配方式分别是identity_provider、permission_scope和audit_sink。前两个控制用户身份来源和权限范围第三个决定审计日志写到哪里。如果你不做任何修改直接跑默认使用内存版模拟登录和本地文件日志适合开发预览。生产环境必须替换成你们自己的身份认证服务和审计数据库这一步省不了。4.3 如何接入你们自己的企业系统拿到开源代码后接真实系统的路径建议分三步走切忌一上来就接所有业务。第一步先接只读接口。把日程查询、联系人查询、项目状态等没有写操作的工具接入让用户在对话框里能通过自然语言查看信息。这个阶段主要验证意图识别和目标系统的数据映射即使出问题也不会造成实际影响。第二步再接低风险写操作。比如创建待办、发送提醒、生成草稿。这些操作即使有误员工也能随手改正。接入时要重点测试权限映射确保不同角色能看到和操作的数据范围与原来系统完全一致。第三步最后才考虑高风险写操作。像报销提交、审批通过、删除数据这类一定不能只靠模型判断必须设计二次确认流程并且把权限校验放在工具层而不是模型提示词里。模型只负责想做什么风控系统只允许有权限做什么这两个决策必须彻底分开。这个阶段有一个特别实用的惯例在适配器接口里加一个dry_run参数。所有写操作都支持干跑模式接完系统后先让 AI 在干跑模式下走一遍流程确认生成的操作记录、权限校验和日志输出完全符合预期再放开真实执行。5. 实测效果与避坑总结让 AI 从能跑到好用5.1 内部八个月的实际数据内部试运行八个月参与部门从最初的三个扩展到全公司。从系统统计看日均主动使用次数稳定在一千一百次左右其中最多的三个场景是日程协调、知识库问答以及各类申请草稿生成。我们做了一个粗略的耗时对比操作场景人工平均耗时使用 AI 平均耗时降低比例新建会议室预约4 分钟40 秒83%报销单预填15 分钟3 分钟80%查制度文件并提取关键信息10 分钟1 分钟90%这个数字不是绝对科学的统计样本有限而且参与团队本身对 AI 接受度会更高。但至少说明方向没问题AI 越来越像一个自动化的执行者而不是一个陪聊面板。相比准确率我更关心员工是否愿意把重复劳动交给 AI 去预执行这个行为信号它比任何指标都诚实地反映产品的价值。5.2 踩过的几个大坑每个都是真金白银换来的第一个大坑过早让模型自动执行一切。在某次迭代中我们把权限校验放在了模型的系统提示词里让模型被指示只有拥有 XX 权限才能执行。结果一次演示中一个员工让 AI 帮另一个同事提交请假审批模型看了上下文里的权限信息没有区分发起人和审批人这两个角色直接越权提交了。事后我们把权限校验整体移出模型放到工具层的permission字段里强制校验才算真正杜绝了这类问题。记住模型只负责生成意图绝不拥有授权能力。第二个大坑工具返回结构不统一。早期每个工具返回的字段各有各的写法有的用err_msg有的用error_message有的报错时干脆返回一个字符串。调度层处理起来非常痛苦还出现过模型把错误字符串误认为正常结果、继续执行后续步骤的 bug。后来我们统一了信封格式要求所有工具返回{ok, data, trace_id}任何非标准结构直接判定为调用失败。这个标准可能看起来死板但恰恰是这种死板让系统稳定下来。第三个大坑忘记清理过期权限缓存。当时为了加速我们把员工权限缓存起来设置了 30 天过期。结果在这一个月里有人从项目组调走了系统还保留旧权限导致他可以被 AI 引导去操作一个已经不属于自己的资源。后来我们把权限缓存有效期缩短到 1 小时同时增加变更事件主动失效机制才彻底解决。权限是个动态的东西任何时间维度的延迟都可能变成安全漏洞。第四个大坑没有成本预算控制。大模型调用不是免费的。有一段时间内部不限量开放某个同事用脚本一次性问了一千个知识库问题当天的云账单直接涨了很大一截。后来我们在调度层对所有请求打上项目标签并且为每个部门设置月配额超过之后自动降级到小型模型回答基础问题既保住了预算又保证核心体验不中断。5.3 开源之后的一些实践体会写到这里想聊聊把项目开源之后的感受。开源并不是把代码往外部仓库一推就万事大吉你还得持续回答 issue、整理文档、更新示例。这个过程很花时间但它逼着我们把很多只有内部人才懂的暗知识写成了公开文档。比如为什么调度层用规则加模型混合为什么确认动作必须独立于模型判断这些以前只在会议里讲的事情现在都有了公开可查的解释。对使用者来说这些文档比代码本身更有价值。如果看完这篇你也想在企业内部做一个类似的工作伙伴我的建议是不要先买一个大模型然后到处找场景而是先梳理你们的业务系统里哪些操作频率高、人工成本高、出错代价低从这些场景切入用小步快跑的方式迭代。开源框架可以帮你节约大量底层的开发时间但真正让 AI 变成工作伙伴的关键在于你敢不敢把系统里那些最繁琐、最需要细心的流程放心地交给一个可持续追踪、可审计的执行体。最后再分享一个小技巧我们内部所有 AI 工具默认都开着确认模式。员工点确认的那一刻其实就是对 AI 的信任投票。每多一次确认点击都比单次准确率更有意义。这也是我从整段实践里得到的最深体会——企业 AI 落地本质上不是模型能力竞赛而是流程设计、权限边界和人机协作信任链的构建。