在企业里做AI智能体我踩过最大的坑不是模型不够聪明而是全自动三个字把业务部门全吓跑了。智能体一旦自己决策、自己执行、自己给出结论中间没有任何人来把关出了问题谁都担不起这个责任。我参与DeepMiner这个企业级AI智能体平台的开发时从一开始就明确了方向不做全自动黑盒而是做人机协同。所谓人机协同不是把AI当作一个独立工作的员工而是把它设计成一个随时可以被人类介入、检查、纠正、兜底的协作者。这篇文章想跟你聊聊DeepMiner在企业级场景下做智能体开发的整体思路、架构设计、人机协同机制的具体落地方式以及我们在实操中遇到的各种问题和排查经验。内容偏实战既讲为什么这么设计也讲怎么一步步实现适合正在做企业级AI应用、想把AI Agent落到业务里但又担心失控风险的技术团队参考。1. DeepMiner项目我们到底在解决什么问题1.1 企业引入AI智能体的三个现实困境先说背景。DeepMiner这个项目最初是因为业务侧的一个具体需求被拉起来的数据部门每天要花大量时间做重复性的数据查询、指标解释和报表解读大量人力被消耗在查一下上周的转化率为什么跌了这类高频但相对标准的问题上。团队想用大模型来替代这部分工作但真往企业里落地的时候我们发现事情远不是接一个模型API、写一段Prompt那么简单。第一个困境是模型的不确定性。大模型生成的SQL可能语法正确但逻辑错误生成的结论可能看起来成立但口径跟业务定义不一致。这种不确定性让业务部门不敢直接把AI的输出用于决策因为一旦数据错了最终背锅的仍然是业务团队。第二个困境是数据权限和合规问题。企业数据有严格的分级管理制度不是所有员工都能看所有数据。智能体如果拥有过大的工具权限一个普通运营人员通过智能体就能查询核心收益数据这就是严重的安全事故。权限控制必须从设计之初就嵌入系统而不是事后补救。第三个困境是信任问题。用户不信任一个黑盒给出的结论。人机协同的核心价值也在这里——AI把活干完人在关键节点把方向然后双方对结果达成一致共识。这个共识过程本质上是把AI从输出结论变成给出建议并接受校验。1.2 为什么是人机协同而非全自动做企业级产品时全自动是一个看起来很诱人但实际很难落地的目标。全自动意味着系统要在无人干预的情况下独立完成所有环节这对模型的准确性要求是99.99%而当前大模型即使配合工程手段也很难达到这个级别。人机协同的思路完全不同我们不追求AI在所有环节都正确而是把整个任务流程拆解成多个节点在关键节点设置人机握手。AI负责那些高密度、低风险、标准化的工作比如数据检索、初步分析、报告草稿撰写人负责那些高风险、高判断成本的工作比如目标确认、口径校准、最终决策。我在DeepMiner里把这种协同拆成三个层面来落地。第一层是分工协同明确人和AI各自负责哪些环节第二层是校验协同AI给出结果后人有权检查、修改、驳回第三层是反馈协同人的每一次纠正都会转化为系统后续优化的依据。这三层合在一起才构成一个完整的人机协同闭环。2. 系统架构与核心设计思路2.1 DeepMiner的整体架构DeepMiner的整体架构可以拆成四层。最上面是会话接入层负责对接企业内部的IM、Web端、办公套件让用户能以自然语言的方式发起任务。这一层本身不承担复杂的业务逻辑只负责把用户的输入标准化传给下一层。第二层是编排调度层这是整个智能体的大脑。这一层负责理解用户意图、拆解任务步骤、决定调用哪些工具、管理任务状态。DeepMiner在这里内置了一个轻量的工作流引擎可以把一个复杂任务拆成多个子任务并且支持人工审批节点的插入。编排层就像餐厅里的传菜主管他决定哪个菜先做、哪个厨师负责、什么时候上桌而不是自己亲自炒菜。第三层是能力组件层包括SQL执行器、Python代码执行器、报表生成器、文档检索器等一系列工具。每个工具都被封装成标准的接口模型通过函数调用的方式来使用它们。第四层是数据安全与治理层统管权限控制、数据脱敏、操作审计、敏感词过滤。这里想强调一下工具这个概念。很多第一次做智能体的人会以为工具就是把API给模型调用就行了但企业级场景下工具必须有非常明确的使用边界。我们的SQL执行器在底层做了两层防护第一层是权限过滤根据当前用户的数据权限自动改写查询条件第二层是只读设置绝不允许智能体执行任何写操作。这两层防护确保了即便模型意图理解出错也不会造成数据越权或者数据损坏。2.2 模型选型与能力组件设计模型选型上DeepMiner采用的是主模型辅助模型的混合方案。主模型负责复杂推理、任务规划、结论生成选择的是参数规模较大、中文理解能力强、工具调用稳定的通用大模型辅助模型负责一些简单但高频的任务比如意图分类、实体抽取、敏感信息识别这类任务用轻量模型就能完成响应速度更快、成本也更低。举个例子用户在对话框里输入帮我查一下华东区上周的销售额环比变化主模型负责把任务拆成定位数据表—生成SQL—执行查询—计算环比—生成解读这几个步骤而辅助模型则在一开始就完成销售数据类问题的分类标注方便系统快速匹配对应的提示词模板和工具集。能力组件这一层我们的设计原则是最小可用但可扩展。第一版上线时只做了四个核心工具SQL查询器、指标计算器、报表生成器、知识库检索器。每个工具都有明确的入参、出参、错误码。后续业务方提出新需求时我们只需要在能力组件层新增一个工具不需要改动编排层的逻辑。2.3 为什么企业级必须可插拔企业级智能体和普通个人助手的最大区别在于需要对接企业内部各种异构系统。不同部门的数据口径不同不同系统的数据表命名风格不同不同业务线的指标定义也不同。如果把这些差异全部塞进模型的Prompt里很快就会发现上下文被撑爆而且维护困难。DeepMiner采用可插拔设计来解决这个问题。我们把每个业务域的知识封装成独立的领域包包括数据字典、指标口径、常用查询模板、权限规则。当用户发起一个任务时编排层先做领域识别然后只把相关的领域包加载进模型的上下文。这样既保证了专业度又控制了Token消耗。这种设计带来的直接好处是新业务域接入时不需要重新训练模型只需要配置一套新的领域包。我们最快的一次上线只花了两天时间就是因为业务域的知识沉淀完全走配置化路径。这也是企业级落地时一个非常关键的设计决策后期你会省无数的事。3. 人机协同机制把人设计进系统里3.1 人在环中的四个关键节点人机协同不是一句口号它需要落实到具体的技术机制上。DeepMiner在设计时确定了四个必须有人参与的节点我逐个说一下。第一个节点是任务启动前确认。当AI理解完用户意图、准备执行任务时如果任务涉及敏感数据、批量操作或跨部门数据查询系统会先把AI的行动计划展示给用户由用户确认后再继续。这个机制有效地避免了因为一句含糊的指令就引发一串错误操作。第二个节点是高风险操作审批。这里特指那些超出当前用户权限、或者会对业务产生直接影响的操作。DeepMiner把审批通道跟企业现有的审批流打通AI执行到这一步时会自动暂停生成一条审批请求推送给该业务域的数据负责人。负责人批了AI才继续执行不批任务直接终止并通知发起人。第三个节点是结果复核。AI生成数据分析结论后不会直接推送给业务方而是会附带完整的数据溯源信息——包括查询了哪些表、使用了什么过滤条件、计算口径是什么、引用了哪些文档。用户可以点开查看如果有疑问可以直接修改条件后重新生成。这个节点保证了最终结论的可靠性而不是盲目信任AI。第四个节点是反馈闭环。每次用户对AI结果做出修改、驳回、追问的时候系统都会自动记录这次的交互内容沉淀到反馈池中。这些反馈数据有专人定期分析用来优化提示词、调整领域包或者补充工具能力形成一个持续改进的循环。3.2 可解释性与决策依据展示企业级场景里可解释性不是可选项而是必选项。用户之所以愿意把自己的判断与AI的结论融合前提是他能看懂AI为什么要这么回答。DeepMiner在生成最终结论之前会让模型先输出一个推理摘要也就是用自然语言简述它的分析思路。我们以可见步骤的方式把AI执行任务的全过程记录展示在界面上意图理解结果、任务规划步骤、每一步执行的状态、工具返回的原始数据摘要。整条链路像流水线一样清晰可见用户可以逐段检查。某一次我们发现业务团队对AI结论的采纳率不高后来调查发现原因是大家看了结论但看不到依据心理上总觉得不踏实。加上逐步可见的链路后采纳率明显提升。可解释性还有一个附带价值它天然就是调试工具。开发阶段工程师可以凭执行记录快速定位是意图识别错了、SQL写错了还是工具执行报错不需要靠猜。3.3 协同模式从助手到协作者在实际使用中我们发现不同团队对人机协同的接受度不一样需要的协同模式也不一样。DeepMiner最终沉淀了三种模式分别应对不同成熟度的用户群体。第一种是人主导、AI辅助。AI负责信息检索和初步整理所有的判断和决策都由人来完成。这种模式适合对AI信任度还比较低的团队。第二种是AI执行、人监督。AI独立完成大部分任务但在关键节点向人汇报人只需要做确认操作。大部分数据分析类任务采用的是这种模式效率和安全兼顾。第三种是AI自治、人抽查。这个模式下AI对低风险、标准化的任务自动闭环执行系统定期抽样检查执行结果。我们只在特定业务域、对系统已经充分信任的情况下才开放这种模式。这三种模式并不是在系统里锁死的而是可以针对不同的任务类型和用户角色动态切换。这个灵活性也是人机协同框架区别于传统工作流自动化的重要特征。4. 实操记录从零搭建一个DeepMiner分析智能体4.1 环境与基础配置接入开发环境时我给团队定了一套标准的基础配置。核心服务用Python编写FastAPI作为接口框架任务队列用的是Redis Streams向量数据库存知识库切片和记忆数据业务数据库用PostgreSQL。模型我们接的是统一的模型网关底层替换模型时上层服务不需要改动。配置的核心是领域包文件。下面是一个简化版的领域包配置示例一个领域包包含数据字典、指标口径、权限级别和常用查询模板。domain_name: sales_analysis tables: - table_name: order_flow_daily alias: 每日订单流水 columns: - name: order_dt desc: 订单日期 - name: region desc: 销售区域 - name: gmv desc: 成交金额单位元 metrics: - metric_name: 销售额环比 formula: (本期gmv - 上期gmv) / 上期gmv * 100% alias_list: [环比, 销售环比] permission_level: L2 query_templates: - tag: 区域销售额查询 template: SELECT region, SUM(gmv) FROM order_flow_daily WHERE order_dt {start_date} AND order_dt {end_date} GROUP BY region这个配置文件的用意是让模型在生成SQL时不是靠猜而是从明确的字段定义和模板出发。我们把AI自由发挥写SQL变成AI根据数据字典组装SQL准确率提升非常明显。4.2 核心流程代码实现DeepMiner的核心任务执行流程分为四步意图解析、任务规划、工具调度、结果生成。下面是一段简化后可以说明思路的伪代码。def handle_task(user_input, user_context): # 1. 意图解析 intent intent_classifier.classify(user_input) if intent.risk_level high: pending_actions.append(await build_action_plan(intent, user_input)) return ask_user_confirm(action_plan) # 2. 任务规划 plan planner.create_plan(intent, user_context) exec_records [] for step in plan.steps: # 权限校验 if not permission_checker.verify(user_context, step.tool, step.params): trigger_approval_flow(step) return wait_approval() # 3. 工具调度 result tool_registry.execute(step.tool, step.params) exec_records.append(result) # 风险节点自动暂停 if step.requires_review: review_result request_human_review(result) if review_result.rejected: return generate_rejection_feedback(review_result.reason) # 4. 结果生成与溯源 answer generator.synthesize(plan, exec_records) return attach_trace(answer, exec_records)这段代码把前面讲的人机协同机制全部串起来了高风险任务先展示行动计划工具执行前做权限校验执行过程中遇到需要人工复核的节点会自动暂停最终生成答案时带上完整的溯源记录。关于审批超时我们实际设的是30分钟。这个时间需要根据业务场景来调太短了审批人来不及看太长了发起人的体验又很差。后来我们加了一个超时提醒机制15分钟未审批时会给审批人推一条自动提醒。4.3 工具调用时机的设计细节设计工具调用时机是我们踩坑最多的地方。一开始我们把工具权限放得很宽模型可以根据自己的判断决定什么时候调用哪种工具结果经常出现模型在不需要查数据的时候强行调用SQL工具、或者在需要查知识库的时候不做调用的情况。后来我们换了一个策略在任务规划阶段先由编排层根据领域包中的标签和模板生成一个大致的工具调用路径把候选工具限定在2-3种之内模型只能从候选集合里选取不能自行调用未授权的工具。这种方式有效降低了误调用率。使用范围限定工具后误调用率大概下降了六成。还需要特别处理的是工具调用结果过长的问题。SQL查询可能返回上千行数据全量塞给模型既浪费Token又容易导致模型注意力被无关数据干扰。我们在工具层加了一个自动化摘要模块当结果集过大时会对数据进行预聚合和排序只把TOP-N条汇总结果和统计指标返回给模型。这样模型看到的永远是最关键的信息生成结论的质量也更稳定。4.4 反馈数据的回收与利用每次人工干预我们都是当作一次珍贵的标注数据来对待的。用户修改了AI生成的SQL说明这条SQL有逻辑问题用户驳回了一个结论说明结论的推理链条有问题用户在追问里补充了一个定义说明领域包里缺了这个口径。DeepMiner把这些反馈统一记录到一个反馈表中每条数据包含原始请求、AI生成的中间结果、用户的修改内容、修改后的结果、触发节点。每周我们会跑一个分析脚本把这些反馈聚合成几个指标各工具的错误率、各节点的驳回率、各业务域的问题分布。这些指标直接决定下一迭代的优化优先级。比如有一段时间华东区销售数据查询的驳回率特别高脚本把驳回记录汇总后发现问题出在区域字段的划分口径上。业务方说的华东区和数据表里的region字段值不完全一致AI按照表里的原始值查询结果自然对不上。我们随后在领域包里补充了口径映射规则这类驳回率立刻降下来了。没有反馈数据的回收机制这种问题可能过了很久都发现不了。5. 常见问题与排查技巧实录5.1 问题速查表把实操中遇到频率最高的问题整理成一张速查表方便大家对照排查。症状根本原因解决方案AI生成的SQL执行结果为空查询条件过于严格或者表分区选择错误在执行层加入自动放宽条件的兜底逻辑并提示用户当前使用的过滤条件同一个问题反复被用户驳回领域包中的指标口径与实际业务不符聚类分析驳回记录定位口径冲突字段更新领域包映射规则智能体不调用工具直接回答意图分类被误导模型判断不需要访问数据调整提示词约束对数据类问题强制绑定工具调用前置条件任务执行到一半卡住无响应审批节点超时或者工具调用死循环增加审批超时自动通知机制任务编排加入最大步数限制AI结论与数据明细不一致模型生成了超出数据范围的结论在模型输入端加入数据范围约束要求结论明确基于给定的摘要数据多轮对话后上下文混淆对话历史过长导致模型丢失关键信息引入上下文压缩机制每轮对话后自动生成会话摘要这张表里每一条背后都有真实的调试过程。拿AI不调用工具直接回答来说我们最初以为是模型能力问题后来抓取完整链路日志才发现是意图分类器把销售数据类问题误分类成了常识问答。修正方式是增加了一个预检规则所有包含数据表关键词的问题必须先经过工具调度模块不允许模型直接回答。5.2 踩坑记录那些文档里不会写的事第一个坑是提示词不是越详细越好。我们第一版给模型写的系统提示词长达3000多字把各种规则、边界、示例都塞进去了。实际效果反而差因为模型在长上下文中容易遗忘早期信息而且详细规则之间存在冲突时模型无法自动取舍。后来我们把提示词精简到800字左右把更多规则移到编排层的代码逻辑里用硬编码方式执行。要注意能用代码约束的规则尽量不要放提示词里提示词只用来引导风格和流程。第二个坑是会话记忆不能无脑保留。企业级场景下的数据会话经常涉及敏感信息而且对话轮数多了之后早期内容可能已经过期。DeepMiner最终采用了摘要式记忆方案每轮对话结束后由轻量模型生成一轮摘要记忆池里只保留摘要和最近两轮的完整内容。这样既保留了上下文连贯性又避免Token浪费和敏感信息滞留。第三个坑是模型反馈给用户的语言风格需要约束。早期版本里AI会用您这样的敬语业务方使用起来有距离感后来调整为简约直接的书面语风格并限制每段回复不超过200字AI只输出结论和关键数据其余细节放进折叠区域。这个细节看起来不起眼但对日常使用体验的影响很大。6. 写在最后一些个人体会以我个人在DeepMiner项目里的实际体会来说企业级AI智能体开发的重心早就从模型选型转移到了行为设计上。模型能力已经不是最大的瓶颈怎么让模型在企业这个复杂环境里负责任地工作才是真正需要投入精力的地方。人机协同的本质概括起来一句话在数据密集、标准化程度高的环节放给AI做在判断密集、责任边界清的环节留给人来做。把这句话变成可执行的工程机制需要的是任务编排、权限控制、审批流打通、反馈回收这些看起来有点不性感但极其重要的基础工作。这部分工作没有炫酷的界面但它决定了智能体到底是一个能稳定产出的生产力工具还是一个偶尔惊艳但不敢依赖的玩具。最后再分享一个小技巧设计人机协同系统时可以先画一个任务失败树。把每个环节可能出错的方式列出来然后针对每个错误方式设计人类的介入方式。你会发现所有该介入的节点都是自然涌现的而不是拍脑袋想出来的。这套方法论从一开始就是DeepMiner项目能顺利走下去的关键也建议所有做企业级智能体的团队都试一下。