“如何让 Agent 在企业里严肃落地、稳定发挥”，是近期在 TiDB 社区活动杭州站 Data + AI 圆桌上的核心议题。

这场圆桌由 Datus.ai 创始人赵恒主持，上台的五位嘉宾则各自代表行业中不同的生态位：德哥是“数据库老兵”、“digoal 德哥”公众号主理人；岛岛来自大模型厂商，是月之暗面 Kimi 开发者关系负责人；郭一军是云贝教育创始人；乐达曾担任 IT 负责人与全栈架构师，现在经营着一家“一人公司”（杭州益丰文化）；TiDB AI 负责人李粒，作为数据库厂商代表，带来 data infra 视角。

同一个问题，五位嘉宾给出的落点却很少重合。正是这些源自不同真实视角的洞察，为我们拼出了一套企业级 Agent 架构评估与落地的判断框架。

以下内容据现场嘉宾发言整理

/一、Agent 从 Demo 到生产，最难的问题是什么？/

大家对难点的感知基本都落在了模型之外。

基于个人 Agent 实践，德哥分享了观念的转变：刚开始深度用 AI 时，把它当成“死”的工具来驱使，“感觉要把人的精力耗光”，因为工具的上限就是使用者本人，而人一天最多也就 24 个小时。转折来自于他看到一位朋友每天上着班还能每周在 GitHub 轻松推进新项目，他开始觉得应该把 Agent “当成孩子来养”，不能指望 Agent 一上来就干活赚钱，而是“要教育它，让它去成长”。

岛岛认为，最大的困难在于企业和组织的数据到底在不在 Agent 的“管辖范围内”。他观察到：传统企业做起来比较困难，因为它们的底层数据甚至都还没有在网上，导致无法与 Agent 应用接轨；但另一边，一些互联网大厂和游戏公司已经在生产环境里大量使用 Agent 了，例如，会议内容有自动化流水线对接给 Agent 做总结分析、项目文件面向 Agent 去设计。尽管不同企业的起步难度不同，他的判断依然很明确：“你得开始做这件事，因为它的复利是非常强的”。

郭一军以金融行业国产数据库一线的具体场景为例。在协助某银行将系统迁移至国产数据库并进行 SQL 优化时，他发现一段应用生成的上千行复杂多表关联 SQL，AI 很难真正理解其背后的业务逻辑。如果直接让 AI 优化，反而“可能带来一些误导”，尤其是对初中级 DBA 而言。这就要求私有数据必须经过训练、任务要精细拆解，且少不了高级专家的“人机交互”审核，绝不能“有了 AI 就让它跑过去执行”。

乐达作为跑过不少工厂的 OPC 创业者，认为最难的是“隐性知识的沉淀”。特别是制造业，或者是一些比较强运维行业的工种上。管理者希望做到 AI 升级转型，但是很多知识，特别是一些隐性的知识，都在厂里面那些老师傅的脑子里，无法沉淀成具体的 skill 或方法论。一旦上生产线出错，“怎么去追责？怎么去追查？能不能在可控的范围内？”都是需要逐步去讨论和验证的。

在李粒看来，针对企业内和企业外场景，难点其实会有所区别。对于企业内部而言，做 Agent 业务最少需要考虑三层：第一层是业务流的抽象，“我们的经验如何转化成一个可描述的流程”；第二层是数据对接，第三层才是搭 Agent。在这个框架下，最难的问题在前两层。而在 Agent 对外服务场景中，搭建初始业务逻辑相对容易，真正的难点在于，当业务面对十万、百万级用户规模时，庞大的 skill 数据量如何承载？怎么做防越权机制、checkpoint？Agent 怎么持续做优化？这些可能是对外服务时真正的压力所在。

/二、Agent 要长期稳定工作，关键在结构、记忆还是基建？/

让 Agent 长期稳定工作最关键的能力是什么？

岛岛的回答从模型出发。他观察到，“现在很多 SOTA Agent 的基模能力已经很强，在一些企业内部调研时发现，一个次 SOTA 的模型其实就已经能应付 90% 的 coding 场景”。既然模型能力不再是最大瓶颈，长期稳定的关键就落在了 Harness 结构上。现在通用的 Harness 很多，面向垂类场景的 Harness 也正在冒出来，面向组织内部具体业务的 Harness 结构将变得非常重要。

德哥和乐达紧盯的则是上下文与记忆治理。德哥发现 Agent 反复犯同一个错，本质是“权重”出了问题：错误信号被反复召回，导致其权重甚至比事后补充的纠正信号还要高。他主张必须进行“记忆分层”，将短期的会话记忆、历史会话、规则边界以及各种 skill/脚本区分开。如果管理不好，“每一轮对话可能产生的质量都是你无法预料的”。乐达也补充指出，一条调用链上会遇到不同的工具、不同的 Memory 和上下文，如果不做归一化和标准化，就很难控制质量；必须收集各个系统的 Golden Case 和 Bad Case，一旦发生变化就重跑验证。

郭一军认为，底层数据必须统一且标准化。在 Agent 通过 MCP 调用各种数据的过程中，如果底层数据发生变化而模型无法理解，就极易在同一个问题上得出不同的结果，从而“产生一些幻觉”。

李粒指出了基建对于实现“Agent 长期稳定”的重要性。客户的一个 session 或 workflow 往往需要连续跑上好几个小时。在这种长耗时工况下，过去针对 SaaS 搭建的传统基建很多行不通——比如 Agent 在写代码并落库的过程中，如果底层的磁盘或 Sandbox 突然 crash，缺少恢复机制就会导致之前的努力付诸东流。以 TiDB 与 Kimi 的合作为例，Kimi 通过 TiDB Cloud File System 在文件编辑的全过程中持续打下 Checkpoint，一旦发生崩溃，系统能立即结合元数据瞬间回到最近的断点继续执行。他强调，进入 Agent 时代，那些过去针对 SaaS 习以为常的存储与底层基建，都值得被重新审视与重构。

/三、企业级 Agent 怎么做到稳定、可靠、可控？/

对于这个问题，嘉宾讨论的方向大致为两类：“从风险出发收缩权限”和“从效率出发重构流程”。

郭一军强调的是金融强合规场景下的严谨底线。他将边界划分为两件事：一是预期的可控（定好能做什么、不能做什么），二是流程的可控。低风险交给 Agent，中风险人机介入，高风险绝对不放权。“如果 AI 乱加索引导致系统撞上‘上游支付通道超时’而大量失败，这个锅谁来背？”因此，他的规则是：“AI 的话，尽量只让它输出建议，或者报告，不会让它进行操作。”

岛岛更侧重人机协作流程的重构。他认为在诸如“供应商入库”这类极其耗费时间、且涉及敏感数据不便交由实习生处理的非标准化场景中，“反而特别适合用 Agent 去落地”。人依然在流程中——“现在已经变成了 Human in the loop”，人的确认（如法务介入、BD 人员复核）被降格成了一次异步的工具调用，保证了业务结果的可靠。而且 Agent 会越用越强，随着信息的积累，下一次任务的成功率和稳定性也会提升。

乐达认为，要做到整体可控，关键在于控制边界与建立“可观测性”。他指出，因为 Agent 的调用链可能是并行、串行或链式的，单次失误带来的后果会像滚雪球，如果不加干预，极易走向失控。他分享道，可以借助 CNCF 孵化的 OpenTelemetry SDK 接口能力采集每条调用链的输入输出、人工介入率、效果达成率等指标。以客服退款场景为例，让 Agent 变得可靠就如同培养实习生：先给规则再给授权，并且权限绝不能只写在提示词里，必须用独立的规则引擎来严格验证。此外，面对数据库延迟等突发状况，他认为 AI 的能力还不够，“还是要靠传统的软件工程来进行补充（如幂等、补偿、追回）”，端到端的治理才是稳定的保障。

德哥对“稳定可靠”的解法，是剥离不确定性，并建立坚实的“状态兜底”。他认为，Agent 大量思考推理的过程，必须被提取出来并沉淀为确定性的 skill 和脚本，这是提高稳定性最直接的方式。而在可靠性方面，他分享了个人踩坑的教训：将会话存在轻量级数据库（如 SQLite）里崩掉后，“历史会话全部都没了”，在危险模式下跑长任务甚至“直接把磁盘给撑爆了”。这意味着，要让 Agent 的执行过程免于灾难，有状态的数据绝不能随意存放，必须有可靠的数据库作为后盾。

李粒顺着可靠性的话题，指出了大规模应用下的基建隐患。如果要让企业里成千上万个 Agent 运行得稳定可控，底层的 Session 存储面临着前所未有的压力。他透露，存有 snapshot、input、thinking、tool call 等全量信息的 Session Event 表会变得极其庞大。过去传统单机数据库单个单元不超过 64 KB 的生产最佳实践，在 Agent 动辄 40 兆到 80 兆的庞大上下文面前完全失效。如果要保证这类具备复杂状态的系统不崩溃、可追溯，“别说 SQLite 了，就是正常的、传统单机数据库，很快就把它撑爆”。底层的强力承载，是实现企业级 Agent 稳定可控的物理前提。

/四、从信息到决策，缺的是哪一环？/

“Data + AI，怎么真正走向 Decision 与 Action？”几位嘉宾给出的思路殊途同归——要把数据和判断一起工程化。

德哥强调了元数据的重要性，以及将不确定转化为确定的必要性。他回顾了没有 AI 的时代：如果一个数据分析师接到经营分析任务，却对库里有什么表、每个字段是什么意思毫无概念，任务根本无从下手。同样，对于 Agent 而言，最基础的是 comment、description 等信息必须完善。他提到某些数据库甚至支持以 KV 对的形式定义到行级的元数据，足见其重要性。但只有元数据还不够，如果每次来指令都让模型重新推理，“有可能就出错了”。因此，走向决策的关键一步是：必须把大量确定性的任务沉淀成 skill——遇到什么任务、写什么 SQL、要不要调脚本、如何出报表，都用 skill 确定下来。把不确定的东西通过这种形式确定化，“才谈得上后面的决策跟 action”。

李粒结合 TiDB 团队的实践与经验积累，进一步指出：如果仅仅是为了展示报表，元信息或许就够了；但要让系统能够真正去做推荐和决策，还缺了 Enrichment（信息增强）。当 Agent 通过搜索发现某些信息或遇到报错时，它需要理解这个信息背后到底意味着什么。系统必须去获取更多数据来辅助判断，评估当前的 skill 和 pipeline 是正常还是异常，最后再形成一份完整的 recommend action 提供给内部人员。把信息增强与建议措施接连起来，数据才真正完成从“展示”走向“闭环决策”的过程。

郭一军提出，走向决策的前提是建立业务抽象与安全防线。Agent 读数据不能简单粗暴地只喂给它表结构，而是要把数据抽象出业务含义，“不然你说你写个 SQL，我意思都不懂，也没用”。同时，由于金融级场景要求极高，系统在做决策时，必须将“只读”与“修改数据”的权限严格分开，不能让模型随意执行写操作。不仅如此，就像 DBA 执行操作前需要经理复核一样，Agent 的决策也必须有校验机制去理解业务规则，甚至要建立“多个 Agent 交叉校验”的体系，以此来防范低级错误。

乐达结合“一人公司（OPC）”的实战，指出 data + AI 能够走向决策的核心在于数据治理与个人经验的迭代。他以每天需要根据热点和国学文章高频生成营销内容的工作流为例：当系统大量产出内容后，他发现不同热点文章竟重复引用了《易经》中相同的典故。此时系统需要做的“Action”，不仅是去修改引用的内容，更深层的是要解决底层的“数据治理”问题——如何让各种经典古籍与每日热点进行更精准的“撮合协商”。在这个过程中，操作者也需要将自己的个人经验加入到 AI 的赋能中，不断完善优化工作流，最终“把个人的经验沉淀为组织能力，一次次迭代”。

岛岛则将“能不能验证”作为敢不敢交给 AI 决策的刻度。他指出，半年前大家还在讨论要不要手写代码，而现在讨论的已经是“还要不要看 AI 写的代码”——因为越来越多流程可以让 AI 自己去验证。他先是以 AI for Science 领域为例：最近有很多头部大模型在探索前沿科学与数学问题时，最终要做的事是让 AI 编写 Lean（形式化证明语言），去严谨地验证其证明过程是否成立。在岛岛自己的实践中也是如此，AI coding agent 大概超过 3/4 的时间都在做验证工作。正因为有这样的验证机制，人类对 AI 做 Decision 与 Action 的信任度得以提升，让 Agent 做自主决策的覆盖率也会越来越高。

/总结/

一场圆桌探讨下来，几位嘉宾的答案是多维度的：

1. 让 Agent 从 Demo 走向生产的关键难点，在于业务抽象、数据对接与隐性知识的沉淀，以及 Agent 对真实业务语义的理解和必要的人机协同。
2. Harness 结构、上下文与记忆治理、标准化的底层数据，以及提供断点续跑等能力的底层基建，都是支撑 Agent 长期稳定运行的关键。
3. 基于业务风险等级划分的人机协作权责、Human in the Loop、可观测性监控与规则引擎约束，以及可靠的数据库底座是让 Agent 可控的重要思路。
4. 完善元信息、沉淀确定性推理过程、前置抽象业务含义并交叉校验，引入信息增强闭环、建立可执行的验证机制，有助于 Agent 真正跨越信息展示，走向决策与行动。

面对从 Demo 迈向严肃生产的这道“坎”，你的团队准备好自己的解法了吗？