- 产品派

CodeTalk小站 · 2026-08-05T12:54:36.283Z

做 LingBase AI（灵基）这个企业智能体平台，并不是为了搞个炫酷的演示 Demo，更多是来自日常工作里真实的观察和痛点。之前公司推进内部 AI 转型，大大小小的 AI 工具和 Agent 原型看了很多。公开的 Agent 案例演示效果通常很漂亮：自动查数据、调用工具、一键完成业务变更。但落到企业真实环境，完全是另一回事。 Prompt 写得再严格，模型依然会自作主张跳过约束。数据写入没有强制拦截。操作记录只存在对话上下文，刷新页面就丢了。想接到飞书、企微还要自己从零写对接。权限、审批、审计全部要二次开发。市面上现成产品，要么是公有云 SaaS，很难深度私有化改造。要么太重，定制成本高。我就想着不如自己动手造一套，一方面当技术实践，把大模型应用全链路完整跑一遍。另一方面希望解决企业落地最头疼的可控性问题，把“人机审批、操作审计、权限管控”从附加功能，做成平台底层运行时的一部分。最开始只是想简单做个智能体调度外壳，开发走着走着发现，真正的难点根本不是对接大模型。对接模型、写 RAG、做可视化工作流，这些属于看得见的部分。真正耗时间的，全是企业场景那些“不发光”的工程问题。比如 HITL 人机确认，如果只做简单弹窗，模型会绕过确认状态继续往下执行，必须在服务端做硬闸门，不能只靠 Prompt 道德约束 AI。所有任务状态、审批记录不能存前端浏览器，全部下沉服务端账本，保证换设备、重启服务依然可以审计追溯。SQL 写库、高危工具调用，不能交给模型自觉，要区分读写副作用，强制触发审批链路。过程踩了不少坑：大模型返回 JSON 格式飘忽不定，经常夹杂 Markdown、注释，解析逻辑反复打磨。本地调试一切正常，部署后工具调用参数偶现丢失。多渠道（飞书/企微/钉钉）消息模型各不相同，要做一层统一抽象适配层。权限 ACL 结合组织树越做越复杂，要在灵活和简单之间不断权衡。还有很多看起来很美的捷径，比如前端模拟任务回放，最终选择放弃，演示好看，但企业生产环境对不上真实运维链路，容易埋下隐患。项目做到中期，我也没有优先堆更多花哨能力，而是反复模拟实施视角：如果给内部同事交付，怎么验证这套平台真的能用？不是输出长长的功能清单，而是完整跑完一遍闭环：配置智能体、绑定知识库、发起任务、触发人工审批、执行工具动作、查看审计日志。能完整跑通这一整套流程，比一堆宣传名词实在得多。我对这个作品的定位很清晰：不做玩具 Demo，面向私有化企业场景。大模型负责推理、思考。平台负责管住边界：谁能用、什么动作需要审批、每一步做了什么都留痕，高危操作不能随意执行。我不希望企业使用 AI 被迫二选一：要么好用但不可控，要么安全但很难用。目前产品还在持续迭代，很多细节还在打磨。做 Agent 的同行应该都有体会，企业 AI 落地，技术框架不难，难的是把治理、管控、可审计真正融入底层运行逻辑，而不是事后补丁，这也是我这段时间做这个项目最大的感受。

CodeTalk小站

3小时前