专场出品人：王昊奋
同济大学 长聘教授 博士生导师
同济大学长聘教授、博士生导师，聚焦知识图谱与知识增强大模型研究，核心成果包括企业级开源知识图谱OpenSPG、全球首个知识增强推理开源模型KAG-Thinker（超万次GitHub星标）、大模型记忆原生操作系统MemOS（单日调用超50万次），大模型评测众包平台AI-Ceping（月活30万人次）成果已落地机场调控、金融风控、座舱交互等多场景。近五年出版学术专著3部，以第一/通讯作者在CVPR、WWW、ICLR、ACL、AAAI、IJCAI等顶级会议与期刊发表论文45篇，谷歌学术被引次数超过1.1万，单篇引用超5400次，并获得DASFAA 2025最佳学生论文、HCII 2024最佳论文等。主持新一代人工智能国家科技重大专项课题、国家自然科学基金重点/面上项目、上海市基础研究特区计划等省部级以上项目4项，获授权专利8项。主讲本研课程9门，指导本硕博学生近40名。获中国交通运输协会科技进步一等奖、MUSE设计创意奖银奖、CCF科技进步三等奖等。担任全球最大中文开放知识图谱社区OpenKG首任轮值主席，兼任Data Intelligence执行主编、CCF自然语言处理专委会秘书长、CIPS语言与知识计算专委会副秘书长等多项学术兼职，在IJCAI、VLDB、世界人工智能大会、中国计算机大会等作特邀报告，长期推动知识图谱与大模型领域的学术创新与产业转化。
Agent上下文与记忆工程
专场定位：Agent的"大脑"构建——从短期上下文管理到长期记忆与自演进学习机制。
内容覆盖维度：
▪ 上下文工程：超长上下文窗口管理、上下文压缩与检索策略
▪ 记忆架构：短期/工作/长期记忆的分层设计、向量数据库选型（Mem0/Cognee等）
▪ Agent自演进：AReaL 2.0在线强化学习、Agent Trajectory Data Protocol
▪ Loop Engineering：从"完成任务"到"在使用中学习并改进"的自演进循环
▪ 记忆的持久化、共享与隐私保护：跨Session记忆、多Agent记忆隔离
郭庆涛
从中国朝代兴衰谈 AI Coding ：zhikuncode 的全局一体化设计
蚂蚁集团 AI技术专家
蚂蚁集团技术专家，26年3月阿里D2大会主会场"AI超级个体"主讲人（介绍一人复刻豆包+Manus+龙虾的经历）
议题背景：
每个模块都变强，整个系统就会更好吗？作为 zhikuncode（对标 Codex、Claude Code）的开发者，我结合开源实现与实际运行，分享交互、模型、Agent、工具、授权和部署如何共同服务于一个任务。借中国唐宋明清制度变迁中的分工与协调问题，追踪局部选择带来的信息变化、责任转移和长期成本，拆解自主与控制、统一与差异、使用便利与维护负担之间的取舍，并给出判断一项改动是否改善整体的审查方法。
内容大纲：
1. 一个人负责整个产品，要同时考虑什么
每个模块都变强，整个系统就会更好吗？作为 zhikuncode（对标 Codex、Claude Code）的开发者，我结合开源实现与实际运行，分享交互、模型、Agent、工具、授权和部署如何共同服务于一个任务。借中国唐宋明清制度变迁中的分工与协调问题，追踪局部选择带来的信息变化、责任转移和长期成本，拆解自主与控制、统一与差异、使用便利与维护负担之间的取舍，并给出判断一项改动是否改善整体的审查方法。
内容大纲：
1. 一个人负责整个产品，要同时考虑什么
1.1 从明代废相后的协调问题谈起：机构撤了，原来的工作由谁承担？
洪武废相后，六部直接对皇帝负责；后来内阁以“票拟”起草意见，由皇帝裁定。起草意见与最终裁定的职责区分，也有助于讨论 AICoding 的分工：调查和方法选择交给模型后，目标取舍、操作批准与结果整合仍需明确承担者。职责表用于检查工作量是否减少，以及是否转移至用户、模型或维护者。
1.2 回到完整的 AICoding 产品：能力、体验、自主程度、用户控制和成本，怎样放在一起权衡？
zhikuncode 由模型选择求解方法，程序维护执行身份、授权与运行结果，用户确定目标和取舍。可编程环境支持模型编写脚本、调用已有程序并读取结果；工程中的代码与规格供后续任务读取和复用。授权、验证和成本控制随执行能力共同设计。
洪武废相后，六部直接对皇帝负责；后来内阁以“票拟”起草意见，由皇帝裁定。起草意见与最终裁定的职责区分，也有助于讨论 AICoding 的分工：调查和方法选择交给模型后，目标取舍、操作批准与结果整合仍需明确承担者。职责表用于检查工作量是否减少，以及是否转移至用户、模型或维护者。
1.2 回到完整的 AICoding 产品：能力、体验、自主程度、用户控制和成本，怎样放在一起权衡？
zhikuncode 由模型选择求解方法，程序维护执行身份、授权与运行结果，用户确定目标和取舍。可编程环境支持模型编写脚本、调用已有程序并读取结果；工程中的代码与规格供后续任务读取和复用。授权、验证和成本控制随执行能力共同设计。
2. 分工之后，谁把系统重新组织成一个整体
2.1 从唐宋分工方式的变化看协调：职责拆开以后，信息与责任怎样衔接？
唐前期中书起草、门下审核、尚书执行，宰相另在政事堂共议；宋初民政、军政、财政分属不同机构。职责划分还需要议事与信息汇合机制。多 Agent 的设计同样需要明确按处理环节还是工作对象分工、哪些依赖跨越边界，以及整体结果由谁整合。
2.2 用户、模型、主从 Agent 与程序如何配合：谁作决定、谁执行、谁反馈，谁对最终结果负责？
以 MOBA 游戏开发为例，主 Agent 将已知状态、相关文件、已尝试的修改、预算和验收要求交给子 Agent，通过顺序接力复用工程中的代码与检查脚本。该任务说明成果接续的过程，后续运行时实现则用于展开委派合同，以及模型、工具、授权、预算和退出交付条件的配置。
唐前期中书起草、门下审核、尚书执行，宰相另在政事堂共议；宋初民政、军政、财政分属不同机构。职责划分还需要议事与信息汇合机制。多 Agent 的设计同样需要明确按处理环节还是工作对象分工、哪些依赖跨越边界，以及整体结果由谁整合。
2.2 用户、模型、主从 Agent 与程序如何配合：谁作决定、谁执行、谁反馈，谁对最终结果负责？
以 MOBA 游戏开发为例，主 Agent 将已知状态、相关文件、已尝试的修改、预算和验收要求交给子 Agent，通过顺序接力复用工程中的代码与检查脚本。该任务说明成果接续的过程，后续运行时实现则用于展开委派合同，以及模型、工具、授权、预算和退出交付条件的配置。
3. 一个局部改动，会牵动哪些其他部分
3.1 用户从另一设备介入任务：交互、后台执行、授权与运行状态怎样共同响应？
以跨设备介入作为设计场景：用户从另一端追加一句“先完成本地预览，暂不发布”。结合已有的输入、授权与重连机制，沿“收到、保存、应用、进入模型请求、实际执行”逐段说明生效条件。需求回答与操作批准分别处理；本次操作与获准时冻结的对象保持一致，后续操作能否复用授权则按范围和当前条件核对；重连状态与当前任务对应。
3.2 模型与任务安排发生变化：上下文、缓存、执行预算和过程产物怎样共同支撑接续与纠偏？
上下文压缩保留工具调用与结果的完整配对及用户原话，并核对实际发送给供应商的请求与预算参数。普通入口在当前模型内分层处理重试与续写；发生模型切换时，按相应路径和配置剥离不兼容的私有状态，重新计算窗口。后续任务通过主动读取已有文件接续工程成果。
以跨设备介入作为设计场景：用户从另一端追加一句“先完成本地预览，暂不发布”。结合已有的输入、授权与重连机制，沿“收到、保存、应用、进入模型请求、实际执行”逐段说明生效条件。需求回答与操作批准分别处理；本次操作与获准时冻结的对象保持一致，后续操作能否复用授权则按范围和当前条件核对；重连状态与当前任务对应。
3.2 模型与任务安排发生变化：上下文、缓存、执行预算和过程产物怎样共同支撑接续与纠偏？
上下文压缩保留工具调用与结果的完整配对及用户原话，并核对实际发送给供应商的请求与预算参数。普通入口在当前模型内分层处理重试与续写；发生模型切换时，按相应路径和配置剥离不兼容的私有状态，重新计算窗口。后续任务通过主动读取已有文件接续工程成果。
4. 什么必须统一，什么应当允许不同
4.1 从清代不同文书通道与留存安排看信息流转：及时决策与后续接续为什么需要配套考虑？
题本批示后抄发执行，原件存档；奏折批示后发还遵办，原折缴回，另录副本备查。办理、存档与查考具有不同用途和使用者。工具结果也分别服务于程序、模型和用户：运行记录供程序判定状态，正文支持模型选择后续行动，界面供用户查看和决策。三者形式可以不同，结果语义应当一致。
4.2 统一目标、授权和状态口径，同时保留不同模型、工具、任务与运行环境所需的差异。
统一执行身份、批准对象、状态含义、资源归属及成果版本与验证范围，保留模型协议、求解方法和工具实现的差异。以普通任务执行链和 Gateway 代码说明执行前复检、短事务登记开始与事务外工具调用；再沿结果处理和跨语言代码审查，追踪记录的实际读取位置及其含义。
题本批示后抄发执行，原件存档；奏折批示后发还遵办，原折缴回，另录副本备查。办理、存档与查考具有不同用途和使用者。工具结果也分别服务于程序、模型和用户：运行记录供程序判定状态，正文支持模型选择后续行动，界面供用户查看和决策。三者形式可以不同，结果语义应当一致。
4.2 统一目标、授权和状态口径，同时保留不同模型、工具、任务与运行环境所需的差异。
统一执行身份、批准对象、状态含义、资源归属及成果版本与验证范围，保留模型协议、求解方法和工具实现的差异。以普通任务执行链和 Gateway 代码说明执行前复检、短事务登记开始与事务外工具调用；再沿结果处理和跨语言代码审查，追踪记录的实际读取位置及其含义。
5. 能力不断增加，整个系统怎样持续演进
5.1 预装能力还是按需运行：首次使用的便利，怎样影响部署、资源占用和升级维护？
预装程序与字体可以减少任务现场的准备工作，同时增加镜像体积、构建时间和版本维护成本；按需安装则将等待和安装失败的处理留到任务执行阶段。接入能力时，分别验证程序安装、服务就绪、工具对模型可见、路由可达和目标动作完成。
5.2 模型替换、工具更新与能力退出：如何处理已有依赖、在途任务和过程产物，判断旧机制是否仍然合适？
替换前明确旧机制的消费者、在途任务与需保留的成果，再按依赖梳理、最小共同规则、小范围接入、迁移及反例验证、收益测量与约束复核五步推进。沿用第四章的操作，以批准核对表说明交付物、承担者和验收；以 worktree 为例，说明确认静止后对成果归属与整合条件的检查。
预装程序与字体可以减少任务现场的准备工作，同时增加镜像体积、构建时间和版本维护成本；按需安装则将等待和安装失败的处理留到任务执行阶段。接入能力时，分别验证程序安装、服务就绪、工具对模型可见、路由可达和目标动作完成。
5.2 模型替换、工具更新与能力退出：如何处理已有依赖、在途任务和过程产物，判断旧机制是否仍然合适？
替换前明确旧机制的消费者、在途任务与需保留的成果，再按依赖梳理、最小共同规则、小范围接入、迁移及反例验证、收益测量与约束复核五步推进。沿用第四章的操作，以批准核对表说明交付物、承担者和验收；以 worktree 为例，说明确认静止后对成果归属与整合条件的检查。
6. 怎样判断一次改动改善了整体
6.1 以减少重复确认为例：同时检查用户收益、授权边界、执行责任与异常处理。
同一次操作必须与获准时冻结的对象一致；后续操作即使参数或目录变化，也应按已有授权的范围与当前条件判断能否复用，并在执行前复检。取消后迟到的批准不能重新开放已关闭的执行准入。收益评估同时记录不必要的确认、误放行、误拒绝和维护成本。
6.2 用 MOBA 游戏开发、代码审查及失败记录检验设计，结合使用和维护反馈，明确结论的适用范围。
明代考成通过登记事项、设定期限和按簿查核明确办结依据。工程评价分别判断任务标记完成、运行结束、检查通过和需求满足。通过 MOBA 的检查方法校准，以及代码审查中清理失败、资源登记与后续准入关系的调查，提出执行退出前后的资源与准入检查，区分问题定位与接受修复的依据；再以固定条件的最小对照评估机制的投入价值。
同一次操作必须与获准时冻结的对象一致；后续操作即使参数或目录变化，也应按已有授权的范围与当前条件判断能否复用，并在执行前复检。取消后迟到的批准不能重新开放已关闭的执行准入。收益评估同时记录不必要的确认、误放行、误拒绝和维护成本。
6.2 用 MOBA 游戏开发、代码审查及失败记录检验设计，结合使用和维护反馈，明确结论的适用范围。
明代考成通过登记事项、设定期限和按簿查核明确办结依据。工程评价分别判断任务标记完成、运行结束、检查通过和需求满足。通过 MOBA 的检查方法校准，以及代码审查中清理失败、资源登记与后续准入关系的调查，提出执行退出前后的资源与准入检查，区分问题定位与接受修复的依据；再以固定条件的最小对照评估机制的投入价值。
听众受益：
1. 学会从完整产品出发审视架构，识别一个模块的改进对其他部分产生的影响。
2. 掌握追踪收益、代价与责任的方法，判断工作是真正减少了，还是转移给了用户、其他模块或后续维护。
3. 理解任务分工、上下文、授权、执行预算和过程保存之间的配套关系，避免孤立调整某个参数或机制。
4. 将安装、首次使用、部署、升级与能力退出纳入同一次设计考虑。
5. 带走一组可用于技术评审的问题：改善了什么、影响了谁、需要哪些配套、如何验证、何时应重新调整。
1. 学会从完整产品出发审视架构，识别一个模块的改进对其他部分产生的影响。
2. 掌握追踪收益、代价与责任的方法，判断工作是真正减少了，还是转移给了用户、其他模块或后续维护。
3. 理解任务分工、上下文、授权、执行预算和过程保存之间的配套关系，避免孤立调整某个参数或机制。
4. 将安装、首次使用、部署、升级与能力退出纳入同一次设计考虑。
5. 带走一组可用于技术评审的问题：改善了什么、影响了谁、需要哪些配套、如何验证、何时应重新调整。
丛广林
从个人记忆到团队资产：Agent 记忆的进化与开源之路
腾讯云 数据库高级研发工程师
负责 TencentDB Agent Memory 内核研发
议题背景：
Agent 越来越能干，却常常无法继承上一项任务的背景、决策和经验。本次分享将介绍 Agent Memory 如何从个人偏好记忆演进为团队资产，重点讲解 Chat Memory、LLM-Wiki、Code Graph 和 Skill 四类资产，以及 Proxy、Core、权限治理和任务闭环等核心设计。最后结合 Demo，分享 TencentDB Agent Memory 的开源进展与共建方向。
Agent 越来越能干，却常常无法继承上一项任务的背景、决策和经验。本次分享将介绍 Agent Memory 如何从个人偏好记忆演进为团队资产，重点讲解 Chat Memory、LLM-Wiki、Code Graph 和 Skill 四类资产，以及 Proxy、Core、权限治理和任务闭环等核心设计。最后结合 Demo，分享 TencentDB Agent Memory 的开源进展与共建方向。
内容大纲：
1. 为什么 Agent 总像刚入职
1.1 Agent 能力不断提升，但任务之间缺少项目状态的继承。
1.2 Memory 的价值，是让 Agent 从团队已经知道的地方继续工作。
1.2 Memory 的价值，是让 Agent 从团队已经知道的地方继续工作。
2. 从个人记忆到团队记忆
2.1 个人记忆解决使用的连续性，团队记忆解决经验的继承。
2.2 团队资产需要兼顾共享、权限和治理边界。
2.2 团队资产需要兼顾共享、权限和治理边界。
3. 团队记忆的四类核心资产
3.1 Chat Memory：历史背景与决策。
3.2 LLM-Wiki：当前有效的项目知识。
3.3 Code Graph：代码与数据对象的关联。
3.4 Skill：经过验证的团队方法和流程。
3.5 介绍资产化、原子化、相关性优先等设计原则。
3.2 LLM-Wiki：当前有效的项目知识。
3.3 Code Graph：代码与数据对象的关联。
3.4 Skill：经过验证的团队方法和流程。
3.5 介绍资产化、原子化、相关性优先等设计原则。
4. 系统总体架构
4.1 Proxy 根据任务、角色、权限和预算动态编排上下文。
4.2 Core 管理资产、版本、权限、来源和使用记录。
4.3 在线请求与异步资产处理分离，保证系统稳定和可演进。
4.2 Core 管理资产、版本、权限、来源和使用记录。
4.3 在线请求与异步资产处理分离，保证系统稳定和可演进。
5. 治理与任务闭环
5.1 权限、质量、生命周期、可信度、审计和成本治理。
5.2 形成“干完有沉淀、换人不重来、开局就读档”的任务闭环。
5.2 形成“干完有沉淀、换人不重来、开局就读档”的任务闭环。
6. Demo 与开源共建
6.1 展示团队记忆如何在真实任务中产生、使用和更新。
6.2 介绍当前开源进展、后续 Roadmap 和社区参与方式。
6.2 介绍当前开源进展、后续 Roadmap 和社区参与方式。
张凌钧
基于 Milvus 与 Zilliz Cloud 构建面向生产的 Agent 记忆检索系统
Zilliz 解决方案架构师
关注向量数据库、语义检索与 AI 应用的数据基础设施。围绕 Milvus 与 Zilliz Cloud，开展技术交流、方案设计和验证工作，重点关注 RAG 与 Agent 场景中的数据组织、多用户检索、检索质量、性能容量和部署运维。注重从实际业务需求出发，分析开源自建与托管服务的适用条件，将功能需求转化为可验证的工程目标。本次分享将结合公开案例，从数据基础设施的视角讨论长期记忆的架构设计与生产化取舍，区分记忆策略、检索服务与数据库各自承担的职责。
议题背景：
Agent 记忆常常被等同于"给 Agent 接一个向量库"。但在生产环境中，记忆是一组分层的存储问题：会话状态和工作记忆放在上下文与 KV 存储里，规则与用户画像往往只是几个文件或几行配置；真正需要检索系统的，是持续累积的原始历史，以及做了记忆抽取的系统中那些规模更小、但频繁改写的事实与事件。即使在需要检索的地方，向量、全文与图也不是互相替代的关系，图记忆同样需要检索来找到入口。
本次分享从向量数据库一线支持的视角出发，结合 Milvus 与 Zilliz Cloud 上多租户检索、持续写入与数据更新等真实负载的一线观察，先回答"哪些记忆需要数据库、需要什么样的检索"，再拆解两类数据的工程问题：原始历史层的多用户隔离、模型更替与冷热成本；抽取记忆层的写入查重与读写一致性、版本与时间、改写与遗忘。最后给出一张记忆存储选型图和一份上线验收清单。
内容大纲：
1. Agent 记忆的分层：哪些记忆根本不需要向量库
Agent 记忆常常被等同于"给 Agent 接一个向量库"。但在生产环境中，记忆是一组分层的存储问题：会话状态和工作记忆放在上下文与 KV 存储里，规则与用户画像往往只是几个文件或几行配置；真正需要检索系统的，是持续累积的原始历史，以及做了记忆抽取的系统中那些规模更小、但频繁改写的事实与事件。即使在需要检索的地方，向量、全文与图也不是互相替代的关系，图记忆同样需要检索来找到入口。
本次分享从向量数据库一线支持的视角出发，结合 Milvus 与 Zilliz Cloud 上多租户检索、持续写入与数据更新等真实负载的一线观察，先回答"哪些记忆需要数据库、需要什么样的检索"，再拆解两类数据的工程问题：原始历史层的多用户隔离、模型更替与冷热成本；抽取记忆层的写入查重与读写一致性、版本与时间、改写与遗忘。最后给出一张记忆存储选型图和一份上线验收清单。
内容大纲：
1. Agent 记忆的分层：哪些记忆根本不需要向量库
1.1 一次回答动用哪些记忆：工作状态、规则、画像、事实、历史与关系
1.2 每一类记忆的常见存储：上下文、文件、KV 与关系库、向量、全文与图
1.2 每一类记忆的常见存储：上下文、文件、KV 与关系库、向量、全文与图
2. 什么时候需要检索系统
2.1 判断条件：规模、查询类型、语言与模态
2.2 图与检索的配合：为什么图记忆也需要检索入口
2.3 原始历史与抽取记忆：需要检索的两类数据
2.2 图与检索的配合：为什么图记忆也需要检索入口
2.3 原始历史与抽取记忆：需要检索的两类数据
3. 原始历史层：海量个人数据的检索底座
3.1 多用户隔离：四级布局的取舍，"一个用户一个集合"的代价，路由不等于授权
3.2 模型更替：长期积累的数据换一次 Embedding 要付出什么
3.3 冷热与成本：为长尾用户付多少钱
3.2 模型更替：长期积累的数据换一次 Embedding 要付出什么
3.3 冷热与成本：为长尾用户付多少钱
4. 如果做了记忆抽取：数据层要为"记对"提供什么
4.1 写入路径：写之前先查，读写一致性与幂等写入
4.2 版本与时间：记住"改过"，而不只是"现在"
4.3 改写与遗忘：Upsert、删除与 TTL 背后的系统代价
4.4 召回：把一句话拆成过滤、全文、向量与时间感知排序
4.2 版本与时间：记住"改过"，而不只是"现在"
4.3 改写与遗忘：Upsert、删除与 TTL 背后的系统代价
4.4 召回：把一句话拆成过滤、全文、向量与时间感知排序
5. 选型与验收
5.1 记忆存储选型图
5.2 自建 Milvus 与 Zilliz Cloud 的责任分界
5.3 上线前验收清单
5.2 自建 Milvus 与 Zilliz Cloud 的责任分界
5.3 上线前验收清单
听众收益：
1. 一张记忆分层与存储选型图：分清哪些记忆用上下文、文件或 KV 就够，哪些才需要检索系统。
2. 理解向量、全文与图在记忆检索中的配合方式，避免"非此即彼"的选型。
3. 原始历史层的工程方法：多用户布局、模型更替与冷热成本的评估。
4. 抽取记忆层的工程要点：写入查重与一致性、版本与时间建模、改写与遗忘的代价，以及一份上线验收清单。
1. 一张记忆分层与存储选型图：分清哪些记忆用上下文、文件或 KV 就够，哪些才需要检索系统。
2. 理解向量、全文与图在记忆检索中的配合方式，避免"非此即彼"的选型。
3. 原始历史层的工程方法：多用户布局、模型更替与冷热成本的评估。
4. 抽取记忆层的工程要点：写入查重与一致性、版本与时间建模、改写与遗忘的代价，以及一份上线验收清单。
Agentic AICon 组委会是由业界多位资深技术专家发起，负责组织技术指导委员会，并和委员会的专家一起挖掘全球软件工程领域的创新技术，同时依托智盟创课国内领先的人才能力提升服务供应商，组织专业的会务服务团队，全面推进会议的顺利落地，保证参会者体验。
服务总线：400-183-9980
商务合作：151-2264-3988 木子
票务联系：185-1306-7287 静秋老师
E-mail：speaker@qecon.com.cn
关注SECon公众号
添加SECon小助手，获取
会议最新资讯
