在大模型快速发展的几年中，技术的爆发推动了大量多智能体框架的出现。很多企业开始尝试用多个 Agent 拆任务、调工具、跑流程，希望让系统具备更强的协作能力。但在真实业务中，我们发现不少 Agent Swarm 仍然依赖固定路由、复杂 if-else 和冗长 SOP。业务简单时它能跑，一旦流程变化、工具增多、边界 Case 出现，系统就会变得越来越难维护，甚至出现“规则越多，判断越乱”的问题。

EvoMap 团队围绕这个问题做了 4590 组对照实验。实验发现，多智能体系统的瓶颈并不只是模型能力，也不只是 Agent 数量，而是经验无法在系统中流动。传统的过程式技能更像一份写死的操作说明，在稳定流程里有效，但面对动态环境时很容易失效。一个 Agent 今天踩过的坑，明天新唤醒的 Agent 依然会重来一遍。

本次分享将结合 EvoMap 在真实业务中的实验和推演，介绍我们如何从固定编排走向基于 GEP（基因组进化协议）的自进化 Swarm。我们会重点拆解经验如何被压缩成“策略基因”，如何进入共享基因池，如何让新 Agent 在执行任务前继承前人的失败教训。我们也会进一步讨论，当 Agent 系统具备经验遗传能力后，人类在其中的角色会如何变化，以及支撑这种持续进化的底层基础设施需要具备什么能力。

演讲大纲

1. 为什么传统多智能体会在复杂业务里失效

• 多智能体落地中的常见做法：固定路由、长 Prompt、工具堆叠和流程脚本

• 业务复杂度上升后，if-else 编排为何会带来维护成本、误判和协作混乱

• 上下文窗口不是无限空间：把 SOP 和工具说明全部塞进 Prompt，为什么反而会稀释模型注意力

• 多 Agent 不等于群体智能：没有反馈和继承，系统只是更复杂的自动化脚本

2. EvoMap 的实验发现：过程式技能的边界在哪里

• 基于 4590 组真实环境实验，观察 Agent 在动态任务中的失效模式

• 过程式技能在稳定流程中为什么有效，在变化环境中为什么容易失灵

• 工具误选、幻觉、任务中断和重复踩坑背后的共同原因

• 系统需要的不只是更多规则，而是让失败经验被保存、压缩和复用

3. GEP：让 Agent 从“按流程执行”变成“带经验行动”

• GEP 的核心思路：把专家判断、失败教训和处理策略压缩成可调用的策略基因

• 策略基因包含什么：触发条件、失败原因、处理路径和适用边界

• 全量基因池如何帮助新 Agent 在任务开始前获得前人经验

• 从指令分发到经验传递：多 Agent 协作质量如何发生变化

4. 从踩坑到免疫：自进化 Swarm 的工程闭环

• Agent 面对边缘 Case 时的失败，如何变成系统进化的原材料

• 如何从报错日志、执行过程和人工修正中提取可复用经验

• 策略基因如何被验证、更新并注入基因池

• “单点踩坑，全员免疫”在真实业务中的落地路径

5. 人类角色如何变化：从流程微操到进化规则设计

• 当 Agent 能持续吸收经验后，人类为什么不该继续只做任务分配者

• 人类需要定义什么：目标边界、权限范围、痛感反馈和淘汰规则

• 如何在放权和可控之间建立反馈闭环

• 当经验可以遗传，组织能力如何从线性扩张走向复利积累

实践痛点

• Agent 数量越堆越多，为什么系统没有更聪明，反而更容易乱？

• 复杂 if-else 路由和超长 SOP Prompt，为什么会让多智能体系统越来越难维护？

• 上下文窗口有限，如何避免把所有流程、工具和规则都塞给模型？

• 系统经历了大量失败，为什么新 Agent 仍然会重复踩老坑？

• 报错日志和执行废料如何变成可复用的策略经验，而不是沉睡的历史记录？

• 策略基因如何进入共享基因池，又如何避免错误经验污染整个系统？

• 哪些决策可以交给 Agent 自主完成，哪些节点必须保留人类反馈？

听众收益

• 理解多智能体系统为什么常常停留在“伪协作”阶段：问题不只是 Agent 不够多，而是缺少反馈、继承和经验流动机制。

• 获得一套基于 GEP 的自进化 Swarm 思路：如何把失败日志、专家判断和人工修正压缩成策略基因，让 Agent 团队越用越有经验。

• 重新理解人在 Agent 系统中的位置：从微操流程的人，转向定义边界、反馈和进化规则的人，用更低的协调成本驾驭更复杂的智能体系统。

高端人才服务正从“顾问个人经验驱动”走向“人机共生的组织智能”：客户沟通碎片化、人才库更新滞后、项目协同与复盘难以规模化。TTC 基于 2000+ 客户、上千活跃客户和 300 万人才库，构建多 Agent 蜂群架构：每个客户配置客户对接、客户主管、内部协调 3 个 Agent，并接入 OpenMai 工作台、人才库、Sourcing 与 Supervisor Agent，形成数千个不同类型 Agent 的协同网络。系统通过微信群/飞书/人才库/外网数据接入、任务编排、权限审计、Knowledge/Skill 沉淀与跨 Agent 复用，实现客户响应、人才匹配、项目管理和质量巡检闭环，让 bad case 持续转化为可复用组织能力。

演讲提纲

1. 背景

• 人才服务为什么需要 Agent 蜂群高端人才服务不是简单招聘流程，而是客户需求理解、候选人判断、项目推进、关系斡旋和知识沉淀的复杂协作系统
• 传统模式高度依赖顾问个人经验，客户沟通分散在微信/飞书/电话中，人才库更新滞后，项目复盘难以规模化
• TTC 的判断：Agent 不应只是顾问工具，而应成为人才服务组织中的新协作单元

2. TTC 的多 Agent 服务架构

• 构建了数千个 Agent 参与的服务网络。每个客户配置 3 个基础 Agent：客户对接 Agent、客户主管 Agent、内部协调 Agent
• 顾问侧有 OpenMai 工作台 Agent，支持项目管理、候选人匹配、分析与推荐
• 供给侧有人才库 Agent 和 Sourcing Agent，负责人才打标、数据更新、外部信息收集
• 上层有 Supervisor Agent，巡检 Agent 工作质量，发现 bad case，并沉淀 Knowledge/Skill

3. 核心技术点

• 如何让数千 Agent 可控协作以业务对象为核心建模：客户、职位、候选人、项目、沟通记录、任务、Skill，而不是只围绕 Chat Session
• 通过微信群、飞书、人才库、外网信息等多源数据接入，形成持续更新的业务上下文。不同 Agent 拥有不同上下文、权限和工具调用范围，客户可见信息与内部判断严格隔离
• 采用事件驱动机制触发任务更新、候选人推荐、项目风险提醒和质量巡检
• 通过 Skill Registry 管理可复用经验，让不同种类 Agent 能受控学习和复用能力

4. 踩坑经验

• 从“会回答”到“会服务”只靠长上下文不够，群聊中的省略表达必须落到结构化业务状态里。只让 Agent “推荐候选人”，容易退化成简历搜索，必须拆成硬条件、行业匹配、职业路径、动机风险等维度
• Agent 自动总结 know-how 容易空泛，真正有用的 Skill 必须是可执行、可验证、可复用的操作方法。Supervisor 不能只制造告警噪音，需要区分高风险 bad case 和普通低质量输出

5. 实施效果与组织进化

• TTC 已在真实客户服务中运行数千个不同类型 Agent，覆盖客户沟通、内部协作、人才管理、外部 sourcing、质量巡检等环节。顾问从信息处理者升级为 Agent 指挥者、关键判断者和关系经营者。人才库从静态简历库进化为动态人才认知网络。组织经验从“留在个人脑子里”变成可沉淀、可复用、可迭代的 Knowledge 和 Skill。最终形成“人类顾问 + Agent 蜂群 + 组织知识”的共生进化体系。

演讲痛点

• 最大的痛点不是“让 Agent 工作”，而是让大量 Agent 在真实业务中可控、可信、可持续进化
• 人才服务上下文高度碎片化，微信群/飞书里的省略表达、客户隐含偏好、候选人动态状态，不能只靠长上下文解决，必须沉淀为结构化业务对象，但这会增加建模成本
• Agent 越多，职责越细，响应越快，但协作、权限、成本和故障定位复杂度也会上升
• 自动化越深，效率越高，但客户沟通、候选人推荐、状态写回等高风险动作必须保留人工确认，否则容易出现错误承诺和权限越界
• Supervisor 和 Skill 机制能让 bad case 变成组织能力，但也需要评估与版本治理，避免错误经验被规模化复用

听众收益

1. 获得大规模 Agent 落地的组织级架构参考

• 了解如何从单个 AI 助手升级到数千 Agent 协作网络，包括角色拆分、事件驱动、权限隔离、Supervisor 巡检和 Skill 复用机制

2. 理解 Agent 与业务系统融合的关键工程取舍

• 学习在微信、飞书、人才库、外网数据等复杂上下文中，如何处理长上下文不足、业务对象建模、工具调用边界、人工确认和成本控制等问题

3. 看到 AI Native 组织进化的真实案例

• 从 TTC 的人才服务实践中，理解 Agent 如何与人类专家共生：Agent 负责信息处理、流程推进和经验沉淀，人类负责判断、信任、关系和关键决策

在 Agent 的生产力爆发的今天，作为一个产品的负责人，我经常要碰到一个十分棘手的问题：用户提出想要一个新的功能，我有自己在审美和工程上的要求，有在产品自身逻辑自洽上的要求，可是我的时间不够，一周一个功能也许还可以，但是当面临一周 50+ 个 issues 的时候，哪怕有 Agent 的帮助，我也愈发力不从心，我没有时间去一个个设计产品和定位问题，有时候光是复现和确认一个 bug 就需要消耗一个下午的时间。

可是把他们交给同事呢？为了确保产品的方向是正确的，是经过合理的设计的，我们需要同步会议或者同文档，哪怕是一个小 bug 的修复，也需要架构师与工程师的充分沟通，在这些事情上，我经常受到协作摩擦的困扰。

而现在，我们可以做到五个人的范围内，一周迭代一个路由 80 万行代码的项目数十次，修复 80+ issues，且保持高质量，所有决策都经过了我们所有人的确认和 review。

演讲提纲

一、生产力爆炸背后，是个人算力的天花板

AI 让每个人的产出速度翻了几倍，但问题不是"做得不够快"——而是快出来的压力，全砸在了最稀缺的资源上：人类的判断力。

面对一周 50+ 个核心 Issues，传统"一周一个功能"的节奏彻底失效。AI 工具确实提高了单兵效率，但它替不了你做产品审美、架构自洽的判断。确认一个 Bug，从复现、定位、判断是否真的是 bug，到发现它牵扯产品方向甚至架构改动——一个下午就没了，而这只是 50 个里的一个。

更痛的是另一面：当团队里每个人的生产力都爆炸了，管理者面对的不是“大家产出不够”，而是大量无法被下放的决策，最终一定会汇聚到你这里。与此同时，当执行层的活都是 Agent 在干，你更难判断交上来的东西质量到底怎样——协作的不透明性反而增加了。

我们试过增加人力，但结果是：为了对齐产品方向，会议、文档同步、跨角色沟通的成本吃掉了人力增加带来的所有收益。

二、5 个人，一周 80+ Issues，数十次迭代

这是我们团队真实的节奏——在一个 80 万行代码级别的项目里，每周修复 80+ Issues，迭代数十次，且保持极高的交付质量。每一次提交、每一个决策，都经过全团队的确认与 Review。

5 个人，前后端加 PM，没有什么特别的超能力。

我们做到的关键不是“让每个人写代码更快”，而是把决策前移到了一切执行开始之前。

三、反正最后一定会打回来，不如一开始就把决策做完

传统流程是：分任务 → 写代码 → Review → 发现方向不对 → 拉会 → 打回 → 重做。这条路径里，"打回"几乎是必然的，因为执行者在动手时根本没有足够的上下文去做对。

我们的做法反过来：在一行代码都没写之前，就把关键决策聊清楚。

具体来说：

• 任务分发的那一刻，决策者先把产品方向、边界条件、架构约束全部以上下文的方式给出去
• 执行者先写 Code Plan，而不是写代码
• Code Plan 在团队内交叉 Review——这个阶段改一句话的成本，比后面改一千行代码低一百倍
• 确认无误后，上下文完整交接，执行者（或 Agent）才开始实现

这不是一个“AI 帮你写代码”的工具。这是一个管理工具——用来释放决策者的压力，让人类判断力只花在最值得花的地方。

我们打破协作摩擦的方式，不是让沟通更快，而是让大部分沟通变得不再需要——因为上下文在最开始就已经对齐了。

四、新时代需要新的管理手段

AI 改变的不只是"怎么干活"，它正在重塑"怎么管人"。

当执行成本趋近于零，管理的核心从“监督执行”变成了“设计决策流”——谁在什么时机做什么判断，上下文怎么无损地流向下一个环节。

这本质上是一个管理工具。不是给工程师用的效率工具，是给决策者用的杠杆——让你的判断力能覆盖 10 倍的产出，而不是被 10 倍的产出淹没。

我们相信，这是新时代的管理手段：不是更多的会议、更厚的文档、更密的 standup，而是在源头把决策做对，然后让上下文自己流动。

实践痛点

强制避开了一个人闭环全部流程，会一定程度上削减迭代效率，但是做到了极高的工程质量。

听众收益

技术 Leader，苦于 Agent 干活太快，bug 越来越多，自己的团队人工根本审不过来，而 AI 又无法确保工程质量。

过去几年，Zilliz 在商业化进程中实现了持续的高速增长，但我们没有选择“业务增长一倍、人力扩张一倍”的传统路径。面对不断增长的客户需求、产品复杂度和组织协作成本，Zilliz 选择将 AI Agent 深度嵌入企业运营体系，让 Agent 不再只是效率工具，而成为组织执行层的一部分。

Zilliz Agent 最初只是飞书等办公入口中的智能助手，负责知识问答和信息检索。随着逐步接入 Zendesk、GitHub、Grafana、Jenkins、Snowflake、HubSpot 等核心业务系统，它开始参与客户支持、问题分析、代码 Review、内部协作、用户教育以及异步任务跟进等真实业务流程，并逐渐演进为连接客户、员工与企业系统的统一智能入口。

本次分享将结合 Zilliz Agent 的真实落地案例，重点介绍 Agent 如何在企业环境中实现跨系统协作，以及背后的关键工程实践，包括上下文预算管理、长期 Memory 设计、Skills 工程化、Human-in-the-Loop 机制和异步工作流构建。我们还将进一步讨论，当 Agent 从简单问答演进为业务执行主体后，对数据基础设施提出了哪些新的要求，以及 Agent-Native Data Infrastructure 将如何成为下一代企业智能系统的重要底座。

演讲大纲

1. 为什么业务超线性增长需要 Agentic-Native 组织

• 软件公司的增长瓶颈正在从开发效率转向核心人才吸引、组织效率围绕关键员工进行建设的新挑战
• 客户、工单、知识与流程复杂度增长带来的挑战
• Agentic-Native 的核心理念：让 Agent 承担组织中的重复认知与跨系统协调工作，并让 Agent 能力随企业扩张持续成长
• 从“人处理任务”到“人调度 Agent，Agent 调度系统”

2. Zilliz Agent 的演进之路：从办公助手到企业超级员工

• 第一阶段：知识问答与统一信息入口
• 第二阶段：连接企业核心业务系统
• 第三阶段：参与客户支持与内部工作流
• 第四阶段：成为用户与企业之间的智能对接层

3. 企业 Agent 落地的关键工程实践

• 长期 Memory 与超大 Context 构建：如何服务好客户需要一个企业级 Context，而非独立 Session
• Human-in-the-Loop/Graph：构建人与Agent流程迭代闭环
• 大量幕后的同学需要适应走到台前：组织架构调整与团队角色重定位
• 实时与离线任务：Agent 如何从即时响应走向持续协作

4. Deep Agent Workflow 对数据基础设施的新要求

• 企业级 Context 与独立 Session 间的双向迭代支撑
• 离在线一体统一检索与混合搜索
• 权限感知与安全访问控制

5. 实践效果与未来展望

• Zilliz Agent 在客户支持、知识复用和内部协作中的实际价值
• Agentic-Native 组织带来的效率提升与边际成本下降
• 从 Copilot 到 Operator：企业 Agent 的下一阶段演进
• Agent 如何成为未来企业增长的新基础设施

实践痛点

• 业务增长后，工单、客户问题、内部知识和协作成本都在增长，如何避免支持团队线性扩张？
• Agent 的上下文窗口是有限预算，不是无限空间，如何做上下文分层和预算管理？
• 组织级 memory 怎么做？
• 工具越多模型越容易乱选，如何通过 Skills 把工具封装成业务能力？
• 哪些事情可以自动做，哪些事情必须 human-in-the-loop？
• Deep Agent Workflow 对数据基础设施提出了哪些新要求？

听众收益

• 理解 Agentic-native 增长的核心逻辑：不是用 AI 替代人，而是用 Agent 降低组织增长的边际协调成本
• 理解为什么 Agent 系统最终会反过来推动数据基础设施升级：统一检索、lake-native、权限感知、混合搜索、按需计算和持续迭代会成为企业 Agent 的底座
• 获得一个来自 Zilliz 内部的真实案例：如何在业务持续多倍增长的同时，用 Zilliz Agent 这种 Agentic-native 系统支撑客户支持、内部协作、问题分析和用户教育