专场：从驾驭工程到 AI 生产力，构建企业级的 AI-Native 基建
本专场聚焦驾驭工程的最新设计框架与落地实践。提示词工程仅针对单次模型交互做指令优化，应用增益已见顶；上下文工程将提示词管控纳入其中，统筹管理模型全部输入信息以保障输出质量；驾驭工程作为涵盖前两者的高阶体系，为大模型搭建完整的外部运行管控框架，支撑规模化、长周期、高质量的企业级AI落地。本专场将分享最新落地经验，涵盖企业级上下文与知识管理，多 Agent 编排与协同，长程任务管理与记忆体系搭建等深度内容。
历任华为软件工程专家、蚂蚁集团研发智能化负责人、字节跳动资深研发效能架构师，现任某大型公司 AI 基建负责人；曾主导千人级研发团队的研发模式变革，建成蚂蚁研发洞察、字节 DevMind 两大效能体系，现专注 AI 基础设施与 AI-Native 组织转型。
擅长领域：大规模组织 AI 能力建设与转型｜通用 AI Agent 产品与技术｜大规模团队效能诊断与治理｜研发效能基建（平台、度量、实践）规划推广｜研发项目与团队管理
擅长领域：大规模组织 AI 能力建设与转型｜通用 AI Agent 产品与技术｜大规模团队效能诊断与治理｜研发效能基建（平台、度量、实践）规划推广｜研发项目与团队管理
专场出品人：单虓晗
专场出品人：张乐
资深研发效能专家、AI 生产力专家
腾讯 智能化软件工程资深技术专家 、研发效能资深技术专家
负责支撑数万人规模的 AI Coding 及智能化工具平台的设计与研发、Harness Engineering 的设计与实现。曾先后就职于百度、京东等国内一线互联网企业及多家世界五百强公司，长期负责研发效能提升、研发效能度量体系建设、敏捷与DevOps实践落地及平台工程体系的研发工作。《研发效能宣言》发起人及主要内容起草人、《AI质效宣言》共同发起人，DevOps运动国内早期布道者与推动者。著作：《软件研发效能提升实践》、《软件研发效能权威指南》；译著：《独角兽项目：数字化转型时代的开发传奇》、《价值流动：数字化场景下软件研发效能与业务敏捷的关键》。知识星球“AI x 研发效能”主理人。
王硕
快手 AI 生产力引擎与生态平台负责人
快手 AI生产力引擎与生态平台负责人。负责快手AI 生产力工具链（MyFlicker）、AI-DevOps工具链（Team、KDev、KTest、KOncall）的规划与落地，推动AI 作为新质生产力在组织提效增产场景的规模化实践。加入快手前，拥有10年美团、华为、IBM等国内外大型研发组织的研发管理和一线开发工作经验。长期关注AI-Native，智能化软件工程（AI4SE）、敏捷（Agile）与精益（Lean）等工程理念，致力于通过AI、工程方法与平台能力提升组织生产力。
待定
待定
快手如何跨越 AI 研发范式升级的组织鸿沟：
从研发提效到组织跃迁的实践
议题背景：
在 AI 编码工具普及后，快手发现“个人提效”并不会自然转化为“组织提效”：多人协作、流程等待、角色分工和烟囱型组织会抵消 AI 带来的效率收益。本议题聚焦快手如何识别并跨越 AI 研发范式升级中的组织鸿沟，通过全员 AI 化、工作流重构、团队能力 Skill 化和 AI-Native 组织转型，实现从研发提效到组织跃迁。
在 AI 编码工具普及后，快手发现“个人提效”并不会自然转化为“组织提效”：多人协作、流程等待、角色分工和烟囱型组织会抵消 AI 带来的效率收益。本议题聚焦快手如何识别并跨越 AI 研发范式升级中的组织鸿沟，通过全员 AI 化、工作流重构、团队能力 Skill 化和 AI-Native 组织转型，实现从研发提效到组织跃迁。
内容大纲：
1. 问题识别：为什么 AI 工具提效没有带来组织提效
1.1 从个人提效到团队提效的落差
1.2 研发协作中的三类摩擦：人与人、人与流程、人与 AI
1.3 标杆团队难以规模复制的根因：组织结构与业务形态限制
2. 认知升级：从研发效能到 AI 生产力
2.1“研发提效 ≠ 组织提效”的核心判断
2.2 AI 研发范式 L1、L2、L3 的演进逻辑
2.3 组织鸿沟的本质：不是工具问题，而是流程、角色和组织重构问题
3. 关键路径：快手如何跨越组织鸿沟
3.1 从 AI × 研发人员，升级为 AI × 所有人员
3.2 从单点工具提效，升级为端到端工作流重建
3.3 从经验文档化，升级为团队知识库与 Skill 化
3.4 从传统职能分工，升级为 PDE、全栈、Agent 协同的新角色体系
4. 实践案例：AI-Native 团队如何跑通组织跃迁
4.1 商业化风控团队：从人工协作到 AI 主导交付链路
4.2 企业应用团队：从 SaaS 交付到 Skill 化服务
4.3 主站技术部：千人级研发组织的“信息-流程-组织”三层重构
5. 总结展望：从组织跃迁走向 AI 生产力体系
5.1 组织鸿沟之后：业务鸿沟成为下一阶段命题
5.2 AI 生产力中心的角色变化与体系化推进
5.3 从研发组织实践走向全员、全团队、全组织 AI 化
听众收益：
- 1. 理解为什么 AI 编码工具普及后，个人效率提升并不必然带来团队和组织效率提升，避免把组织问题误判为工具问题
2. 学习快手从“AI × 研发人员”升级到“AI × 所有人员”，再到“AI × 团队 / 组织”的推进路径，理解工作流、角色分工、知识资产和组织结构如何同步重构
刘玺宇
小红书 AI 工程架构师
小红书质效研发部 AI 工程架构师，自 23 年起长期深耕质量稳定性领域的 AI 相关工作，目前主要负责小红书质量领域 Agent 的架构设计与开发，横向为各业务线提供质量保障。毕业后曾就职于字节跳动，从事 DevOps 中台、稳定性域 Agent 的开发工作。
待定
待定
从人盯流程到流程找人：推荐系统长程发布的 Harness 工程实践
议题背景：
AI Coding 已将代码产出提速，但从代码完成到全量上线，交付效率没有同步提升。构建、测试、发布、检测等平台各自自动化，环节之间却仍靠工程师读取结果、确认条件、手动启动下一步。一条推荐核心服务的发布横跨十几个部署组，平均持续十多个小时，还需要等待次日效果观察窗口；平台能执行动作，却无法替人持续记住目标、衔接等待、处理例外。
我们曾将发布知识沉淀为近 20 万字的 Skill 操作手册，希望模型按说明调用工具。结果只是把“盯平台”换成了“盯模型”：提示词可以描述禁令，却无法替代发布范围、步骤顺序、通过条件这些必须在运行时成立的硬约束；一次参数漏传，就可能使灰度发布越过边界。
问题的本质不是 Agent 会不会调工具，而是一条 Long-Running + Long-Horizon 的流程，谁来承担跨会话的记忆、基于真实现场的推进、不可逆动作前的确认，以及每一步效果的验证。
小红书推荐发布 Agent 因此不把 Agent 当作流程执行者，而是构建了一套 Harness：任务实体保存唯一权威状态，流程模板定义可执行边界，引擎以 Reconciliation Loop 持续推进，外部动作以 Outbox 与效果查证保证可恢复；Agent 只负责理解异常、整理证据、生成处置提案，人只在目标、风险与授权边界上做决策。系统已贯穿代码评审、质量验证与全量上线；当前生产观察中，单次发布平均仍需约 2 次人工介入，而每一次介入都会进入治理闭环，成为扩展自主范围的候选。
AI Coding 已将代码产出提速，但从代码完成到全量上线，交付效率没有同步提升。构建、测试、发布、检测等平台各自自动化，环节之间却仍靠工程师读取结果、确认条件、手动启动下一步。一条推荐核心服务的发布横跨十几个部署组，平均持续十多个小时，还需要等待次日效果观察窗口；平台能执行动作，却无法替人持续记住目标、衔接等待、处理例外。
我们曾将发布知识沉淀为近 20 万字的 Skill 操作手册，希望模型按说明调用工具。结果只是把“盯平台”换成了“盯模型”：提示词可以描述禁令，却无法替代发布范围、步骤顺序、通过条件这些必须在运行时成立的硬约束；一次参数漏传，就可能使灰度发布越过边界。
问题的本质不是 Agent 会不会调工具，而是一条 Long-Running + Long-Horizon 的流程，谁来承担跨会话的记忆、基于真实现场的推进、不可逆动作前的确认，以及每一步效果的验证。
小红书推荐发布 Agent 因此不把 Agent 当作流程执行者，而是构建了一套 Harness：任务实体保存唯一权威状态，流程模板定义可执行边界，引擎以 Reconciliation Loop 持续推进，外部动作以 Outbox 与效果查证保证可恢复；Agent 只负责理解异常、整理证据、生成处置提案，人只在目标、风险与授权边界上做决策。系统已贯穿代码评审、质量验证与全量上线；当前生产观察中，单次发布平均仍需约 2 次人工介入，而每一次介入都会进入治理闭环，成为扩展自主范围的候选。
内容大纲：
1. 交付的新瓶颈：工程师的注意力
1.1 平台动作早已自动化，真正断在平台之间：读取结果、确认条件、启动下一步仍由人接力。
1.2 推荐发布为何天然是 Long-Running + Long-Horizon：跨昼夜等待、步骤强依赖、环境变化、反馈稀疏且错误不可逆。
1.3 从“给模型更多工具和提示词”转向“谁持续承担流程责任”：流程延续归系统、理解研判归 Agent、取舍授权归人。
1.2 推荐发布为何天然是 Long-Running + Long-Horizon：跨昼夜等待、步骤强依赖、环境变化、反馈稀疏且错误不可逆。
1.3 从“给模型更多工具和提示词”转向“谁持续承担流程责任”：流程延续归系统、理解研判归 Agent、取舍授权归人。
2. 反思：Skill 承载知识，却承载不了运行时约束
2.1 从脚本串联到近 20 万字操作手册：知识补得越多，为什么工程师仍必须值守。
2.2 提示词中的禁令无法替代系统中的硬约束：参数默认值、平台隐含顺序、真实状态并不天然在模型上下文中。
2.3 发布范围、步骤顺序、通过条件必须脱离模型推理路径，成为可验证的运行时机制。
2.2 提示词中的禁令无法替代系统中的硬约束：参数默认值、平台隐含顺序、真实状态并不天然在模型上下文中。
2.3 发布范围、步骤顺序、通过条件必须脱离模型推理路径，成为可验证的运行时机制。
3. Harness：可靠推进长程发布
3.1 四个实体：流程模板、任务、引擎、提案——将执行结构、权威状态、持续推进与人工介入分离。
3.2 任务是会话之外的现场：模板版本与参数在发起时固化为基线；进度、平台结果、待办和人工决定持续保存，多实例通过乐观锁协作。
3.3 引擎以 Reconciliation Loop 推进：每次从当前任务状态重新推导可执行步骤，恢复依赖重算，不依赖回放历史。
3.4 外部动作可靠性：Transactional Outbox、稳定动作标识、幂等键与平台效果查证；不承诺 exactly-once，而是 at-least-once + 效果查证。
3.5 人工介入统一走提案：自然语言先生成计划与影响说明，经确认后写入任务；状态变化则重新预演，避免旧计划污染新现场。
3.2 任务是会话之外的现场：模板版本与参数在发起时固化为基线；进度、平台结果、待办和人工决定持续保存，多实例通过乐观锁协作。
3.3 引擎以 Reconciliation Loop 推进：每次从当前任务状态重新推导可执行步骤，恢复依赖重算，不依赖回放历史。
3.4 外部动作可靠性：Transactional Outbox、稳定动作标识、幂等键与平台效果查证；不承诺 exactly-once，而是 at-least-once + 效果查证。
3.5 人工介入统一走提案：自然语言先生成计划与影响说明，经确认后写入任务；状态变化则重新预演，避免旧计划污染新现场。
4. 自主边界：系统何时推进，何时找人
4.1 用四条 admission criteria 划定可自主范围：可观测、可停止/回退、影响范围可控、判断可靠。
4.2 可验证的异常由框架消化：例如调用超时后查证平台事实、有限重试、超限即停。
4.3 涉及业务取舍和线上风险的异常交还给人：系统挂起任务、整理证据与选项，而不是替人决定风险接受度。
4.4 Agent 的角色不是直接执行自然语言，而是从分散事实和业务意图中推导可审阅、可确认的处置方案。
4.2 可验证的异常由框架消化：例如调用超时后查证平台事实、有限重试、超限即停。
4.3 涉及业务取舍和线上风险的异常交还给人：系统挂起任务、整理证据与选项，而不是替人决定风险接受度。
4.4 Agent 的角色不是直接执行自然语言，而是从分散事实和业务意图中推导可审阅、可确认的处置方案。
5. 双闭环：从人工介入中扩大自主范围
5.1 执行闭环保证单次发布持续完成：观察、推进、验证、暂停与恢复。
5.2 治理闭环把每次人工介入的原因、依据、决定与结果沉淀为流程改进输入。
5.3 自主能力不是设计出来的：模板补充、离线评测、影子运行、线上结果验证和明确授权，逐步将可验证场景迁入系统。
5.4 从 Human on the Loop 到 Human design the Loop：人从处理每次例外，转向定义目标、风险边界与授权规则。
5.2 治理闭环把每次人工介入的原因、依据、决定与结果沉淀为流程改进输入。
5.3 自主能力不是设计出来的：模板补充、离线评测、影子运行、线上结果验证和明确授权，逐步将可验证场景迁入系统。
5.4 从 Human on the Loop 到 Human design the Loop：人从处理每次例外，转向定义目标、风险边界与授权规则。
听众收益：
1. 一套长程 Agent 的 Harness 划分原则：将状态、流程推进、外部动作、异常研判和人工授权放回各自能稳定承担责任的位置，而非用提示词兜底。
2. 一组可落地的可靠性设计：权威任务状态、Reconciliation Loop、config-as-of、Transactional Outbox、at-least-once + 效果查证，以及 plan & apply 的人工介入机制。
3. 一套渐进式自主方法：用可观测、可回退、范围可控、判断可靠四个条件划定自主边界；把人工介入转化为可评测、可灰度、可迁入的治理资产。
臧振宇
蚂蚁 AI 安全实验室研究员
蚂蚁AI安全实验室 Data Agent 架构师，长期从事数据智能体系统与企业级 Agent 工程化的研发与落地。
现负责Data Agent 平台的架构重构，主导设计并落地公共 Harness 底座：统一引擎入口与多引擎可插拔架构，支撑双站部署与多业务场景扩展。
现负责Data Agent 平台的架构重构，主导设计并落地公共 Harness 底座：统一引擎入口与多引擎可插拔架构，支撑双站部署与多业务场景扩展。
待定
待定
Data Agent 的工程化困境与破局：
来自蚂蚁 AI 安全实验室的 Harness 架构实践
议题背景：
大模型 Agent 的单点能力已被广泛验证，但在企业级数据场景中——长程多轮任务、严格的权限与数据安全、多租户隔离、双端交付——模型的不确定性被成倍放大，靠提示词优化的“单点做对”无法保证“每次都对”，成为数据 Agent 走向生产的核心障碍。
作为蚂蚁AI安全实验室 Data Agent 团队，我们将DataAgent Bot从单体架构重构为平台化的 Data Agent 系统，以标准化的架构契约构建引擎无关的公共 Harness 底座，在意图驱动的上下文组装、长程会话连续性、记忆与知识即插即用等方面形成了可落地、可迁移的工程方案。本次分享将聚焦 Harness Engineering 范式在数据 Agent 场景的设计思路、落地实践与踩坑经验。
内容大纲：
1. 从 Coding Agent 到 Data Agent：认知基线与适配挑战
大模型 Agent 的单点能力已被广泛验证，但在企业级数据场景中——长程多轮任务、严格的权限与数据安全、多租户隔离、双端交付——模型的不确定性被成倍放大，靠提示词优化的“单点做对”无法保证“每次都对”，成为数据 Agent 走向生产的核心障碍。
作为蚂蚁AI安全实验室 Data Agent 团队，我们将DataAgent Bot从单体架构重构为平台化的 Data Agent 系统，以标准化的架构契约构建引擎无关的公共 Harness 底座，在意图驱动的上下文组装、长程会话连续性、记忆与知识即插即用等方面形成了可落地、可迁移的工程方案。本次分享将聚焦 Harness Engineering 范式在数据 Agent 场景的设计思路、落地实践与踩坑经验。
内容大纲：
1. 从 Coding Agent 到 Data Agent：认知基线与适配挑战
1.1 两类 Agent 的本质差异：输出可验证性、上下文边界、安全模型、错误代价等七个维度的系统对比
1.2 数据 Agent 的三大额外难题：意图不确定、数据不确定、安全不确定——为什么单靠提示词优化走不远
1.2 数据 Agent 的三大额外难题：意图不确定、数据不确定、安全不确定——为什么单靠提示词优化走不远
2. 核心范式：Harness Engineering，用确定性驾驭不确定性
2.1 范式跃迁：从 Prompt 到 Context 再到 Harness，从“单点做对”到“全流程兜底”
2.2 编排与执行分离：流程走向交给确定性代码裁决，模型只负责单点作业——这是 Harness 的第一性原理
2.2 编排与执行分离：流程走向交给确定性代码裁决，模型只负责单点作业——这是 Harness 的第一性原理
3. 落地实践：伊娃 Data Agent 平台的架构演进
3.1 从单体 Bot 到 Agent 平台：分层解耦，引擎与场景插件化，换引擎、加场景不动主干
3.2 意图驱动的上下文组装：按意图决定“查什么、查多少”，记忆与知识并行召回、降级不崩
3.3 长程任务的会话连续性：会话与引擎解耦，跨进程重启恢复对话，历史不绑死在任何一家引擎上
3.2 意图驱动的上下文组装：按意图决定“查什么、查多少”，记忆与知识并行召回、降级不崩
3.3 长程任务的会话连续性：会话与引擎解耦，跨进程重启恢复对话，历史不绑死在任何一家引擎上
4. 难度对比与解法：数据 Agent 的工程挑战怎么解
4.1 七维难度对比与优劣势：为什么 Coding Agent 的 Harness 是锦上添花，Data Agent 的是生存基线
4.2 典型难题的解法映射：意图路由、权限护栏、大结果治理、多租户隔离、故障恢复
4.2 典型难题的解法映射：意图路由、权限护栏、大结果治理、多租户隔离、故障恢复
5. 踩坑经验与收益展望
5.1 典型坑与修复：固定拼装上下文、截断数据让模型猜结论、会话与引擎绑死、长程任务流程发散过早收尾
5.2 已验证收益与认知升级：换记忆、换知识实现主流程零改动的实战验证，从“会调 Prompt”到“能设计 Agent 工程系统”
5.2 已验证收益与认知升级：换记忆、换知识实现主流程零改动的实战验证，从“会调 Prompt”到“能设计 Agent 工程系统”
关注QECon公众号
关注QECon视频号
商务合作
151-2264-3988 木子
票务联系
159-0126-5561 小娟
媒体合作
135-1619-6409 皮皮
购票咨询
小娟 15901265561
