10 月 31 日，TiDB 社区「当智能体成为主力军，Infra 和我们应该如何进化？」线下技术交流会于成都圆满举办。特别感谢盈创动力、盈创星空、亚马逊云科技 User Group、蜀鸿会对本次活动的大力支持！
本次活动围绕 Agent 企业级落地与数据库国产化最新实践两大方向展开。十余位技术专家与行业实践者齐聚现场，覆盖政务、教育、物联网与物业 ERP 的 TiDB 落地案例，数据治理、大数据架构、工业时序数据与 Agent 基础设施的技术实践，以及超级个体到超级组织的协作升级、LLM 推理经济学、AI 数据安全与 NUMA 全栈调优等议题。
照片链接：https://img.pailixiang.com/album/a14133796480/18900608.jpg?x-oss-process=style/pbig&fs=4300854
PPT 下载
01-如何跨越从超级个体到超级组织的鸿沟.pdf （1MB）
02-LLM推理的经济学.pdf (9.1 MB)
03-TiDB在省教育厅的落地与平凯Loop多智能体开发实践.pdf (5.2 MB)
04-物联网园区业态的数据库底座升级与Agent落地.pdf (3.8 MB)
05-让数据被看见-数据治理的业务价值与技术实践.pdf (5.5 MB)
06-TiDB在大数据架构中的工程实践.pdf (5.4 MB)
07-当AI触碰生产-数据安全的真实风险与撤销键.pdf (8.8 MB)
08-模型之外-重新思考AgenticAI的基础设施架构.pdf (6.3 MB)
09-AI时代的工业时序数据分析挑战.pdf (10.6 MB)
如何跨越从超级个体到超级组织的鸿沟？
分享嘉宾：龙恒｜平凯星辰中国区总经理
分享概要：
当每个人的手边都站着强大的智能体，个体效率的提升是肉眼可见的 —— 从 ChatBot 式的人问 AI 答，到 Copilot 式的人做 AI 辅助，再走到“人定目标、AI 执行”这一步，单个人已经成了名副其实的超级个体。可一旦个体能力被拉满，瓶颈反而转移到了组织这一层：目标散落在讨论里缺少共同验收，信息停在私聊里下一位还得重问，进度分布各处对不齐，经验难以复用只能从头再来。平凯星辰中国区总经理龙恒在分享里点破了这个矛盾 —— 超级个体的集合并不等于超级组织，目标、时机和责任不一致，再强的个体也可能相互抵消，所以个人能力上去了，人与人、人与智能体之间的连接必须同步升级。
升级的方向是把协作本身做成体系。平凯 Loop 协作平台让多人多 Agent 围绕共同目标并行开发，任务自动拆分、结果合并、冲突消解，把“只有分工”变成“形成协作”；MeshX 知识飞轮把代码、文档、wiki、聊天里的经验持续回流，越用越聪明；最底层由一套 TiDB 统一承载 ——OLTP 强事务保障业务可靠，TiFlash 列存支撑实时分析，SPFresh 向量检索与全文检索为 Agent 提供知识底座，一套引擎原生支撑事务、分析和 AI 检索，Agent 才真正从对话走向行动。
LLM 推理的经济学——我们拥有的资源与代价
分享嘉宾：唐云峰｜泛灵人工智能联合创始人、SKFI·中韩未来革新加速器社长
分享概要：
泛灵人工智能联合创始人、SKFI·中韩未来革新加速器社长唐云峰，开场介绍了几组 token 消耗数据：有人半年消耗 5 亿 token，有人一天消耗 700 亿，他个人 loop 起来一天约 20 亿。购买设备并不意味着 token 免费，算力、存储、上下文仍各有边界。他借用帕累托前沿解释资源取舍：为控制成本使用 16G 显存机器做实验，N-gram 存放在 SSD、KV 缓存留在显存。结论是目标明确、质量可用时，其余都是工程问题。
他以 Switch 游戏移植为例：将游戏原生移植到 Jetson 上，27B 小模型可以运行，但卡在一个角色名字的显示上。模型类似“害怕犯错的小孩”，242K 上下文用完后反复自我怀疑、验证，一天没有进展。之后他把“允许 agent 犯错”设为工程目标，错误统一收入负向知识库。他认为，agent 走出来的不是正确的路，而是走错了之后剩下的路。并延伸探讨了人与 AI 的责任边界问题。
TiDB 在省教育厅的落地 & 平凯 Loop 多智能体开发实践
分享嘉宾：王海瑞｜成都元素科技售后服务高级工程师、TiDB 社区版主
分享概要：
成都元素科技售后服务高级工程师、TiDB 社区版主王海瑞先分享了一次暑期应急经历：省教育厅暑期防溺水等政务任务逐级下发，高峰流量直接打满原有数据库节点的 CPU、内存与 IO，平台几乎不可用。当时项目明确要求使用国产数据库，而团队已经基于 MySQL 8 开发了整整一年，距上线仅剩一个月就被迫换库，选型标准非常务实——必须强兼容 MySQL、自带分布式高可用能力。TiDB 正好匹配要求：团队当晚就通过 TiProxy 搭建负载均衡救急，第二天流量进一步上涨时连夜扩容，待开学后用户量回落，又顺利完成缩容。在他看来，分布式数据库最本质的价值就是弹性：业务扛得住、需要扩容时能快速扩、流量回落时还能缩回去降本。
数据库问题解决后，王海瑞分享了更具启发的多智能体开发实践：公司服务全国数百家客户，过去故障总要等客户打电话投诉才发现，一直是被动响应。他作为自认“不会写代码”的售后人员，早在两年前就向研发团队提过开发统一监控工具的需求，始终没有排期落地。等到平凯 Loop 开放内测，他注册试用后，仅靠多 Agent 协作就完成了整套工具开发：架构师 Agent 拆分模块、输出架构文档与产品清单，开发 Agent 实现代码，评审 Agent 对照需求文档逐项检查，联调测试 Agent 完成最终验证。他最终交付了两个实用工具：一个是统一 Webhook 告警接收入口，集中承接监控系统的告警推送；另一个是面向学校、教育局老师的图形化软件升级界面——过去需要售后逐户处理、依赖命令行操作的升级工作，现在老师自己就能完成，把售后人员从重复的运维工作里解放了出来。
物联网、园区业态的数据库底座升级与 Agent 落地
分享嘉宾：刘方明｜四川易软运维团队负责人
分享概要：
四川易软运维团队负责人刘方明介绍了物业 ERP 系统的数据库演进过程。公司早期采用 .NET 与 SQL Server，后迁移至 Java 与 MySQL；随着业务增长，单表数据量达到上亿行，一条报表 SQL 可能占用三五十 G 内存。团队先后尝试将内存扩容至 512G、搭建主从、使用 Mycat 与 DBLE 进行分库分表，但问题只是被推迟，分表数量不断增加，运维负担持续加重。最终团队选择 TiDB，主要考虑三点：兼容 MySQL，业务代码几乎无需改动；通过 TiUP 在线扩容，约一分钟即可新增一个节点；具备 HTAP 能力，TiKV 行存与 TiFlash 列存分别承载交易与报表流量，互不干扰。此外，DM、BR、TiCDC 等工具覆盖备份、迁移与同步场景，对运维团队较为友好。
在物联网与园区场景中，水表、电表与传感器 7×24 小时运行，部分设备以秒级频率采集数据，存储成本压力较大。刘方明表示，TiDB 的压缩能力使团队可以用较小的计算与存储资源承载这些数据。数据沉淀之后，AI 管家、员工知识助手、AI 视频与 AI 预警等应用具备了数据基础，可实现违停、火情、温度异常等情况的识别、工单生成与通知。他同时表示，若能重新规划架构，团队会在六年前直接选择 TiDB，而不是先经历从 MySQL 到 TiDB 的迁移过程。
让数据被看见：数据治理的业务价值与技术实践
分享嘉宾：董文平｜成都数驭未来技术总监
分享概要：
成都数驭未来技术总监董文平通过两个业务场景说明了数据治理的实际价值。其一是国际航班入境场景，处置窗口只有数小时，旅客信息、住宿轨迹与学校报到情况需要在研判前汇总到位。其二是地下水超采监管场景，执法人员难以逐户核查，团队通过产量与行业特征推算理论用水量，再与水务、工商、税务数据比对形成差异线索；相关模型上线后在成都发现疑似线索 80 余条，推动办案 62 件，并在全省 21 个市州、80 个基层检察院推广。
在技术架构上，董文平强调做“减法”。去年底的项目原本使用达梦、Oracle、Greenplum、MySQL 与 Elasticsearch 五套主力数仓，选型后以 TiDB 作为核心数仓，由 TiKV 承担事务处理、TiFlash 承担分析处理，数据同步也由 TiDB 自身完成。数据库数量与数据链路随之减少，运维成本下降，数仓的健壮性与数据一致性反而得到提升。最后，针对未来 AI 在数据治理领域的应用，他强调数据质量的上限决定 AI 服务水平的上限。
TiDB 在大数据架构中的工程实践
分享嘉宾：汤维｜广东省第一届智慧城市标准化技术委员会委员、《每天学点填坑小技巧》公众号主理人
分享概要：
广东省第一届智慧城市标准化技术委员会委员汤维以 2022 年一个垂直电商项目为背景，介绍了实时数据链路的建设过程。当时订单流水表约 2000 多万行，订单明细表超过 10 亿行，业务方对成交数据有实时查询需求，而直接查询数据库会导致服务不可用。团队最初采用 MySQL binlog、canal、Kafka 与 Hive 构建链路，只能做到 T+1 交付；引入 TiDB 与 TiCDC 后，实时数据口径才得以打通。最终架构为 TiDB—TiCDC—Kafka—Spark—Hive，一条分支进入数仓，另一条分支回流 TiDB，直接支撑 HTAP 分析。
汤维重点讨论了组件边界、监控告警与容灾预案。他指出，TiDB 负责在线业务与 AP 查询，TiCDC 负责行变更抽取，Kafka 负责缓冲与分发，Hive 负责分层落地，边界不清会显著增加后续的维护成本；实时大屏、超高频小事务以及跨分区强有序等场景并不适合这条链路，实时大屏可直接由 Flink 计算后推送，不经过落库。监控方面，仅关注 Kafka 容量与 offset 并不充分，还需要关注 TiCDC 的任务状态与 DDL 数量、Hive 的写入耗时与小文件数量，并明确告警的响应责任。扩容应以指标为依据，容灾则需提前准备 TiDB 快照、offset 持久化与补数方案。他也坦言该链路较长、故障点较多，all in one 是后续演进方向。
当 AI 触碰生产，数据安全的真实风险与“撤销键”
分享嘉宾：王斌｜成都云祺科技有限公司、高级产品经理
分享概要：
成都云祺科技有限公司高级产品经理王斌分析了 AI 进入生产环境后数据安全面临的风险变化。他指出，客户关注点已从功能强度转向业务能否被安全托付，误删、误操作、勒索加密以及备份中的二次感染等风险往往在事后才被发现，仅依靠权限控制与流程约束只能缩小影响范围，难以提供最终保障。为此，他提出“撤销键”思路，包含两个层面：一是恢复速度，备份系统可直接拉起并接管业务，减少停机损失；二是恢复粒度，既支持按时间点恢复，也支持按对象恢复，只回滚出错部分的数据。
王斌进一步强调，备份系统本身需要被验证，无法成功恢复的备份不具备实际价值。他建议将不可变存储、定时验证、备份系统自身加密与恢复演练纳入统一框架，覆盖事前、事中、事后三个阶段。他总结认为，AI 能力越强，数据安全的重要性越突出。
模型之外：重新思考 Agentic AI 的基础设施架构
分享嘉宾：张津豪｜亚马逊云科技解决方案架构师
分享概要：
亚马逊云科技解决方案架构师张津豪从 POC 与生产环境的差异切入，分析了 Agentic AI 的基础设施需求。在本地验证阶段，规划、上下文管理、链路追踪与权限等问题并不突出；当系统进入生产环境、面对数百至上千个并发会话时，这些“模型之外”的能力成为必须解决的部分。他判断，决定 Agent 能否稳定上生产的关键已转向系统架构，涉及运行时与镜像、记忆分层、工具管理、身份认证、数据与多租户隔离等，模型只是其中的核心组件之一。
在方法论上，张津豪强调“先定义、再迭代”。开发前应与业务方共同确定评测标准，包括红线、质量召回、成本与性能，并从规划、trace、工具选择三个维度进行观测；可观测性可通过 OpenTelemetry 提前接入。工具数量较多时，可在 agent 之前增加一层工具检索，避免上下文膨胀；长任务的中间状态应外置保存，并定期开启新会话清理上下文，同时保持单个 agent 只承担单一职责。他还给出单租户、共享运行时与完全混合三种隔离模式，分别适用于金融政务、业务探索与个人试验等场景。
AI 时代的工业时序数据分析挑战
分享嘉宾：王耀｜清华大学博士后、IoTDB Committer
分享概要：
清华大学博士后、IoTDB Committer 王耀，分享工业时序数据的存储与分析：传感器在设备上不停记录电压、风速这类随时间变化的序列，是工业设备的“心电图”。用 MySQL、实时库或 Hadoop 生态去管，面对海量高频数据往往接不住、存不下、分析难。他所在的团队从 863 计划起步，把 IoTDB 做成 Apache 顶级项目，又孵化企业版 TempoDB 和时序大模型 Tempo，服务了上千家企业。
方案分两层：TempoDB 管存储，TSFile 文件与数据库解耦，端侧采集、边侧汇集、云端存储，跨节点同步直接搬文件，省掉抽数、转换、导入的链路；TempoAI 像“炼丹炉”，把企业数据投喂给时序大模型，既能零样本预测设备趋势，也能训出领域专有模型。他还提到一个联合底座的做法：设备 ID、标签这类静态信息交给 TiDB，传感器产生的时间序列存进 IoTDB，上层先查 TiDB 定位设备，再回时序库取状态量。最后是 Agent——用自然语言就能调数据库、跑分析，部署不再依赖手册和手写 SQL。
国产分布式数据库在政务行业的应用分享
分享嘉宾：王恒｜政务云解决方案专家
分享概要：
政务云解决方案专家王恒介绍了某成都政务云的建设背景与数据库选型思路。该政务云自 2009 年起步，采用企业投资建设、政府购买服务的模式，目前承载 350 多个完成国产化改造的业务系统。王恒总结了政务信息化的三个趋势：一是国产化合规要求提升，CPU、操作系统与核心关系型数据库需进入国测名录；二是建设方式从部门自建转向集约化平台，需支持多租户与资源隔离；三是业务重心从流程跑通转向数据价值挖掘，实时数仓成为普遍需求。
在数据库选型上，平凯数据库与上述需求具有较高匹配度：已进入名录，满足合规要求；兼容 MySQL，降低存量系统迁移改造的难度与成本；具备 HTAP 能力，可用一套集群同时承载 TP 与 AP 业务，无需另行构建 Doris 或湖仓体系。王恒将落地思路概括为「一局一体系、一数仓一平台」：以某局智慧蓉城分平台为例，该平台包含七八个模块，既有历史系统改造也有新建业务，原有 MySQL、Oracle 与 PostgreSQL 各自独立，现统一至一个分布式集群，并配合本地技术人员参与改造，管理难度、采购成本与上线周期均有所下降。
NUMA 架构下的数据库全栈调优
分享嘉宾：李郭凯文｜数据库技术专家
分享概要：
数据库技术专家李郭凯文介绍了 NUMA 架构下的数据库全栈调优实践。随着 CPU 性能提升路径从提高频率转向增加核心数量，再到微架构改进与 Chiplet 异构集成，算力密度不断提高，NUMA 架构带来的跨 die 访存与调度开销也随之增加。团队将优化工作分为三个层次：最底层是硬件选型与 BIOS 参数配置，例如数据库场景通常关闭预取，并根据场景选择内存交织策略；中间层是操作系统，按照实际 NUMA 拓扑为 TiDB、TiKV、TiProxy 等不同节点配置亲和绑定，同时调整网卡中断队列与绑核策略，减少跨节点访问。
最上层是数据库内部的优化，涉及编译器与编译参数、BOLT 二进制优化、自旋锁参数适配、cacheline 对齐以消除伪共享、热路径函数内联等。李郭凯文表示，这类改动对数据库具有一定侵入性，但收益较为明显：与平凯数据库联合调优后，阶段一相对基准版本提升 20% 以上，阶段二提升约 30%，最终形成开箱即用的联合调优版本与配套交付文档。他同时表示，全栈国产化需要硬件、操作系统、数据库与云厂商共同完成优化工作，而不是将适配负担转嫁给用户。
活动花絮
「观后感文章」有奖征集！
一场干货满满的行业实践分享会虽然落幕，但技术交流的余温还在！
无论是数据库行业应用、AI 落地实践的思考，还是个人的参会心得，关于数据库选型、运维收获，都欢迎在社区博客投稿，优质文章即可赢取专属周边（600ml TiDB AI 主题咖啡杯），截止时间：11 月 5 日
