我大概是在第三次被问到“这个报表数据去哪看”的时候才下定决心把公司里的AI从“会聊天的机器人”改造成“能干活的工作伙伴”的。先说背景我们公司内部其实很早就接了GPT-6系列的大模型接口最初只在统一工作台上挂了一个对话入口同事有问题就来问模型能答就答答不上就翻车。最开始大家觉得新鲜一个月后新鲜劲过了对话式AI就沦为了“高级百度”。后来我换了个思路——不要做一个问答机器人而是做一个“开源的企业工作伙伴”。这个伙伴不是被动等指令而是能主动接任务、查知识库、调内部系统、按权限办事的数字员工。我把它做出来后直接开源到了社区结果不少同行私信我说“这才是公司AI该有的样子”。这篇就把整个设计和落地过程掰开揉碎讲一遍包括我踩过的坑、调参的经验、以及那些文档里不会写的细节。1. 项目背景从“聊天机器”到“工作伙伴”的转折1.1 原始需求其实并不复杂事情的起因很简单。我们公司内部有几百号人日常问得最多的不是技术问题而是制度问题报销单怎么填、年假剩几天、某份合同模板在哪、服务器上线流程是什么。这些问题明明都有文档但就是没人看。行政和人事的同事每天被各种重复提问淹没光答疑就占了小半天工作量。最初我们尝试过做一个FAQ问答机器人把常见问题整理成问答对放进知识库效果只能说勉强能用。遇到说法和文档不完全一致的问法模型就懵了。而且问答机器人只能“答”不能“办”。同事问完“报销流程是什么”还得自己打开系统去填单子流程断了。所以真实需求拆下来就是三件事把散落在各个内部文档、Wiki、表格里的知识统一收拢让人用自然语言就能查。把查询结果和内部操作打通比如查完流程后直接帮用户调起对应的审批入口。让这套能力有权限边界谁该看什么、谁不该看什么系统说了算不能所有信息对所有人大水漫灌。这三个需求疊在一起就注定不能做一个“聊天窗口”了得做一个能接工具、能调系统、能管权限的工作伙伴。1.2 为什么选择“自研开源”而不是直接买套件立项的时候市面上其实已经有一些企业级AI助手套件能对接知识库、能做流程自动化。但我们最终没选原因很现实第一数据合规。公司内部的薪酬制度、人事名单、项目招标信息都属于敏感数据不能接受第三方SaaS服务把这些数据拿到云端去处理。我们需要模型接口可以调但数据必须留在内网检索和权限控制必须自己做。第二定制成本。套件产品把流程写死了想改一个字段都麻烦更不用说对接我们自己那套“历史悠久”的内部审批系统了。与其花三个月去适配别人的规则不如自己花一个月把核心链路写出来。第三开源的意义。这一点我要多说两句。很多公司觉得内部工具开源是“把家底亮出去”其实不是。企业AI工作伙伴的核心竞争力在于权限模型、工具设计和领域知识的组织方式这部分是可复用的方法论开源出去反而能吸引社区帮忙找问题、提PR。我们后来收到大量反馈很多改进点都是外面的人帮我们发现的这些价值远超代码本身。所以最终方案是基座模型用GPT-6系列APIAgent框架、知识库、权限模块、对话入口全部自研最后把核心代码开源。2. 整体设计把AI当作“新入职的同事”来培养2.1 角色设定先定岗位再写代码我后来跟很多人复盘这个项目时反复强调一个观点做企业AI第一步不是写代码是给AI写“岗位说明书”。什么意思你招一个新员工不会直接丢给他一个对话框让他自由发挥而是先告诉他的职责边界、汇报关系、能用的工具、不能碰的权限。AI工作伙伴也是一样。如果一上来就把它定义成“全知全能的聊天助手”它会陷入一个尴尬境地什么问题都接什么问题都只给出一半靠谱的答案。我们给这个工作伙伴定的岗位是“企业数字化助理”职责边界写得很清楚负责制度答疑、流程引导、数据查询、报表生成。不负责技术方案设计、不负责代码审查、不回答与工作无关的话题。遇到底层权限不允许的信息直接明说“无权访问”而不是编造答案。所有涉及审批操作的动作必须在用户完成身份二次确认后执行。有了这个岗位说明后面所有Prompt、工具定义、知识库组织都是围绕它来展开的。你可以理解为先画了组织架构里的一个框再往框里填能力而不是造了一个能力再到处找岗位。2.2 能力分层模型、工具、知识的三角关系在架构上我始终把系统拆成三层来看模型层负责“思考”。也就是理解用户意图、拆解任务、决定调用什么工具、怎么组织回答语言。这一层的核心是推理能力和对上下文的把握我们用的GPT-6系列在这方面足够强。工具层负责“行动”。也就是把模型的想法变成实际操作。比如查知识库、读考勤数据、发起审批流、生成报表。工具层是自研的重点每一个工具都要有清晰的入参、出参、权限标注和失败处理。知识层负责“记忆”。也就是企业内部的文档、制度、流程、数据结构和业务术语。知识层我们采用了RAG检索增强生成的方式先把文档分块向量化再在回答前检索出相关内容注入上下文。这三层的关系你可以想象成一个真实员工大脑模型负责想事手工具负责干活记忆知识库负责提供依据。三层缺一不可。如果模型很强但没有工具它就只能说不能做如果知识库很全但模型不会检索它就变成了一本没法查的字典如果工具很好但权限没管住那就是灾难。2.3 技术选型与工具清单直接上我们最终落地用的技术栈给后来者一个参考模块选型选型理由基座模型GPT-6系列API意图识别和多轮对话能力强工具调用Function Calling稳定Agent框架自研轻量框架团队对内部系统最熟框架只做路由和状态管理避免过度设计向量数据库某开源向量数据库轻量版部署简单支持中文分词效果好社区活跃单机即可跑知识库处理自研清洗管线公司文档格式杂Word/PDF/表格需要定制解析逻辑对话前端内部工作台H5 企业IM入口员工日常都在这两个地方不需要额外下载App部署方式Docker Compose内网环境简单直接一套编排文件拉起全部服务这里要特别说下为什么Agent框架选择自研而不是用现成的。市面上的Agent框架确实很多功能也强大但大多数设计目标是“通用任务自动化”抽象层级太厚。我们企业场景下其实只需要三种能力路由决定用哪个工具、记忆保存多轮上下文、权限工具调用前做鉴权。自己写一个轻量的出问题时排查链路短改起来也快。当然如果你团队人力少直接上现成框架完全没问题前提是先把权限模型想清楚不要后补。3. 核心实现关键模块逐一带你撸3.1 系统提示词与角色人格先说清楚你是谁很多人写Prompt喜欢把系统提示词写成一部长篇小说我是反着来的。企业AI需要的是稳定、克制的行为边界不需要太丰富的人格。我们线上实际用的系统提示词大概是这样你是一名企业数字化助理服务于公司内部员工。 你的职责包括制度答疑、流程引导、数据查询、报表生成。 回答要求 1. 优先依据知识库内容回答不要凭空编造。 2. 如果知识库中没有答案明确说“未找到相关信息”并建议用户联系对应部门。 3. 如果用户询问权限之外的信息回复“无权访问该数据”。 4. 涉及审批、删除、修改等操作时必须先请求用户确认并完成身份校验。 5. 回答使用简洁中文关键步骤用编号列出不要长篇大论。这个提示词里最关键的是第二条和第三条。它等于给AI划了一条“允许不知道”的底线。很多AI助手翻车不是因为模型不行而是因为它面对不知道的问题时选择硬编一个答案出来。有了明确指令之后模型会更倾向于承认知识边界这比任何参数调整都管用。实操心得提示词里不要堆形容词不要写“你是公司最优秀的助手”也不要写“用户是上帝要温柔耐心”。这些跟任务无关的描述不仅没用还会干扰模型对任务指令的注意力。企业场景里明确的任务边界比丰满的人设重要一百倍。3.2 工具调用给AI装上“手”光会说是没有意义的工作伙伴必须能调系统。我们把内部系统的能力封装成了一个个工具大体分三类查询类工具查知识库、查员工目录、查考勤记录、查项目进度。流程类工具发起请假审批、发起报销流程、申请服务器资源。生成类工具生成数据报表、生成会议纪要摘要、导出名单。每个工具在Agent框架里注册时都要提供结构化的定义。拿“查员工假期余额”来举例工具描述大概是{ name: query_leave_balance, description: 查询指定员工的年假、事假、病假余额需要输入员工编号。该操作仅限员工本人或HR角色执行。, parameters: { type: object, properties: { employee_id: { type: string, description: 员工编号 } }, required: [employee_id] } }这里有两个细节很容易踩坑。第一个是工具描述必须非常具体。模型是靠描述来理解工具用途的如果你写“这个工具跟假期有关”模型可能什么场景都想用它。我们后来把所有工具描述统一改成“在什么场景下使用输入什么参数会触发什么结果”模型的选工具准确率直接涨了一大截。第二个是权限校验不能只依赖模型。模型说“帮我查张三的请假记录”它可能会调用工具传个张三的名字进去。真正的防线在工具执行层工具在业务代码里必须拿到当前用户的身份凭证再去比对目标数据的权限范围没有凭证直接拒绝。这个逻辑永远不能放在Prompt里靠模型自觉约束。3.3 知识库接入RAG的正确落地姿势知识库是工作伙伴的“长期记忆”这块做得好不好直接决定用户的体感。我们内部文档大概有几千篇格式五花八门有Word、PDF、Excel、还有一堆历史遗留的HTML页面。整个处理管线分四步第一步清洗。把各类文档统一转成纯文本去掉页眉页脚、重复的目录、无意义的空行。Word和PDF里的图片表格暂时不支持但表格会尽量按行转成Markdown格式保留结构。第二步分块。分块大小我们试了多种组合最终感觉最稳的是一个块控制在300到500字之间带50字左右的重叠。块太大检索出来噪音多模型读不过来块太小语义不完整检索出来的内容经常前言不搭后语。第三步向量化。用嵌入模型对每个文本块做向量化处理存入向量数据库。这里提醒一句嵌入模型和问答模型是两回事别觉得主模型能力强就能做嵌入。嵌入模型的选择对检索质量影响极大有条件就多试几个版本用内部问答集做召回率评估再定。第四步检索策略。我们采用了“关键词召回向量召回”双路方案。向量召回找语义相关关键词召回保精度两路结果合并后按相关度排序取Top K注入Prompt。实际跑下来这种混合检索比单纯用向量搜索稳定得多特别是处理“合同模板在哪”这种带有明确实体的问法。提示RAG里的一个常见坑是“检索到相关内容但模型没有引用”。我们后来在Prompt里强制要求模型回答时必须标注信息来源编号如[1][2]这样既能追踪答案出处也能在模型漏看上下文时提醒它回头读一遍。3.4 权限与数据安全所有人都能用但不能所有人都乱用权限这块是我整个项目里最不敢放松的部分。企业AI最大的隐患就是模型不知道谁是老板、谁是实习生它只知道问什么答什么。我们最终形的权限模型是“角色数据域”模型比简单的地主关系再细分一步每个员工有唯一身份和角色列表例如“普通员工”“部门主管”“HR”“财务”。每个工具和数据源都标注允许访问的角色范围例如“假期余额查询”只允许本人和HR访问“部门薪资统计”只允许财务和部门负责人访问。在工具执行层先解析当前用户的角色再去对比工具的数据范围不匹配直接返回“无权访问”并且记录审计日志。这个模型跑起来之后发现一个有意思的现象AI被限制之后反而更有用。以前它能查到任何人的工资员工不敢拿敏感信息问它现在它被锁死在权限边界内大家知道问不到不该问的反而敢放开了用。信任这个东西不是来自AI的“聪明”而是来自AI的“守规矩”。4. 实操过程从第一行代码到全员可用4.1 项目搭建与数据准备最花时间的其实是语料这个项目真正写代码的时间只占三分之一剩下三分之二全花在数据准备上。我们第一批知识库语料主要来自三个渠道行政部的制度文档、人事部的FAQ手册、财务部的报销指引。拿到原始文档后我花了整整两个工作日做清洗和分类。分类维度是两个按部门分行政/人事/财务/IT按语义类型分制度类/流程类/常见问题类。清洗过程中最耗精力的工作是处理那些“内容互相矛盾”的文档。比如报销标准在不同年份的文件里出现过两版数字这种情况如果直接进知识库AI会随机给出一个答案用户一对比就发现错了。解决方法是建了一个“知识库审核清单”每条语料入库前人工确认三件事是否最新版本、是否与已有语料冲突、是否有明确责任人。宁可少入库几百条低质量语料也不能让AI学坏。4.2 模型接入与Agent框架配置把参数调到“稳”GPT-6系列API接入本身不复杂官方文档写了很详细的调用示例。真正需要调的是生成参数。我们线上生产环境的参数值如下参数线上值调参心得temperature0.2企业场景要确定性优先温度越低回答越稳定0.2是折中值top_p0.9保持一定的多样性但不要太高防止跑偏max_tokens1024内部回答不需要很长太长反而容易注水frequency_penalty0.3适度避免重复表达presence_penalty0.2保持原有风格不过度发散这里最关键的参数是temperature。开发阶段我试过0.8回答很“有灵气”但同一个报销问题上午下午能给出两个版本的说法。企业场景里用户不会觉得这是“AI的创造力”只会觉得系统不稳定。调到0.2之后同类问题的回答模式基本固定用户能感受到一个“有规矩”的工作伙伴。Agent框架的配置上我们给每个会话维护了一份上下文记忆上限是最近十轮对话。超出之后做一次摘要压缩把关键信息提炼出来保存在系统状态里。这样既节省token也避免长对话后期上下文被旧消息淹没。4.3 内部渠道串联与部署上线让同事不需要学“怎么用AI”上线前我心里最担心的不是AI能力不够而是同事不愿意用。后来想明白了一点大家不接受一个工具往往不是因为它不够好而是因为它要求人改变习惯。所以我们把入口放在了两个“零学习成本”的地方打开统一工作台能看到一个固定的对话入口企业IM里给工作伙伴建了一个服务号像加了一个同事好友一样可以直接对话。用户不需要安装新客户端、不需要记网址、不需要学Prompt直接说大白话就行。部署层面我们用Docker Compose把服务拆成四个容器API网关、Agent服务、向量数据库、知识库同步任务。内网部署一台8核16G的服务器就够跑日常使用高峰时段稍微有点吃紧就扩容到16核。上线至今没有发生过一次计划外宕机稳定性比我预期好不少。提示部署时一定要把“知识库同步”和“在线推理”拆开。知识库更新时如果直接改线上向量库会出现检索结果“一半新一半旧”的问题。我们采用双库切换机制先把新语料写入备用库全部写入完成后再切换读取指向整个过程对用户无感知。5. 常见问题与排查技巧实录5.1 幻觉问题AI一本正经胡说八道怎么办这是上线后被吐槽最多的问题。典型场景是有人问“公司对加班餐补的规定”知识库里明明有最新文件模型却结合旧文件编出一个过时的餐补金额。排查下来发现根源不止一个分块重叠太小检索引擎把一份文档的同一句话劈成了两半语义不完整。检索召回的相关内容太多太杂模型被干扰选中了一条次优答案。知识库中存在新旧两个版本文件模型没做版本判断随机挑了一个。我们的应对组合拳有三招第一在知识库每个文本块中注入元信息尤其是生效日期和文档版本号第二Prompt里增加指令“如果你检索到多个相互矛盾的答案优先采用生效日期最近的文件”第三也是最重要的把幻觉问题从“模型问题”转换成“检索问题尽可能从源头减少让模型“自由发挥”的可能。跑了一阵之后用户反馈的“一本正经胡说八道”案例明显减少。5.2 权限混乱有人问到了不该看的信息上线第二周有次用户直接问AI“公司上个月离职的人有哪些”按规则只有HR角色能看员工离职名单普通员工不应该看到。但那次因为工具参数里没严格绑定“当前用户角色”导致查询直接穿过来了。这个事故让我把权限校验规则彻底重构了一遍。现在所有工具函数内部强制要求从当前会话上下文里取用户身份信息不接受用户通过自然语言传过来的“身份声明”。也就是说哪怕用户在对话里说“我是HR帮我查”系统也只看单点登录传来的真实角色不信嘴说的。排查技巧在工具执行层每个函数的第一行就做一次角色校验并且把所有校验日志打出来遇到问题可以快速回溯是哪一层放行的而不是整个链路去猜。5.3 调用成本与并发控制别让工资条变成账单GPT-6系列API的调用成本不低尤其是高峰期并发上来之后一天跑下来token消耗量很可观。我们的省钱策略按优先级排全国大模型的对话都有短时记忆先把热点问题的回答结果做一层缓存相同的用户询问完全相同的条件时直接命中缓存不重复调用API。按问题难度分级把流量切到不同规格的模型上。简单制度问答走轻量模型复杂报表生成和跨模块推理才走最强模型。这个分流逻辑和搜索引擎的流量调度是一个思路实测下来成本省了接近40%。对单用户的请求做频率限制避免有人恶意刷接口或者写了个脚本不停地问。我们在线上的API网关上加了每用户每分钟最多10次请求的限制。5.4 知识更新文档改了AI还在用旧数据公司制度经常更新如果知识库同步不及时AI就会一本正经地给过时信息。这一块我们做了两个机制一是文件变更触发同步。知识库源目录接了文档平台的Webhook文档一更新就自动触发清洗和入库任务。二是“数据保鲜期”提示。每次回答末尾会附带一句“该信息来自XX文件更新于X月X日”让用户自己也能判断时效性。这样就算同步链路哪天出了问题用户也会知道去核对原始文件而不是默默信了AI。6. 开源之后给想参考复现的朋友几句掏心窝的话项目开源后的反馈比我预期的好。收到过不少PR和改进建议其中两条已经被我合并进了主线一条是增加更多内网知识库连接器另一条是优化工具调用失败时的报错提示。这也验证了一开始的想法开源的价值不只是“别人能用”更多是“别人帮你想到了你没想到的”。如果你也想在公司内部做一个类似的AI工作伙伴我个人的建议是从最小闭环开始。不要一开始就画一个大蓝图先把“制度问答流程引导”这两个最高频的场景跑通让办公室同事每天真的在用再逐步加数据查询、报表生成等复杂能力。一个每天都在用的简单工具比一个偶尔被夸炫酷的复杂系统有价值得多。权限问题前置设计。功能可以后加权限不能后补。没有权限边界就上线等于把一把没装保险栓的枪发给一个新人。先把角色模型定好哪怕第一期只支持两种角色也要把鉴权链路完整跑通。最后再分享一个我个人的体会做企业AI心态上不能把它当做一个“智能体”而要把它当成一个“真实团队的新同事”。新同事上岗你要给他岗位说明书、给他能用的工具、给他权限边界、给他知识库手册更要给他犯错之后的兜底机制。把这几件事做到位AI自然从一个“会聊天的机器人”变成一个真正能顶班的工作伙伴。