AI 时代，研发提效的关键不再只是让 Agent 更快写代码，而是让团队能持续证明代码“做对了”、质量“兜得住”。本次分享以“事前-事中-事后”Harness Engineering 为主线，结合游戏后端质量验证实践，探讨如何把 Agent 执行、测试策略、集成测试、Review 沉淀与 Skill 评估组织成质量飞轮。分享将从“查杀分离”这一核心理念出发，说明为什么测试需要独立于实现路径，为什么 Agent 自写自测存在认知同源风险；随后展开 TDD、tester skill、lobbytest / ugctest、skill evaluator 四类实践，分别对应事前结构化、事中自动化验证和事后沉淀回灌。最终目标是让人聚焦业务边界、风险判断和质量标准，让 Agent 承担执行、验证与重复性修复，使同类问题越来越少，质量资产持续复利。

演讲提纲

1. 引言：Agent 时代的质量焦虑
   • 最大的问题不再是“能不能写代码”，而是“怎么证明写对了”
   • 研发质量的目标：让问题更早暴露、更少重复、更容易回灌
   • 引出核心框架：事前结构化、事中自动化、事后沉淀
2. 两层 Harness：执行托底与项目组织
   • Agent-CLI 侧 Harness：托住长程执行，控制失控风险
   • 项目侧 Harness：拆清需求、测试、Review 和沉淀入口
   • 最终目标：白天做判断，夜里跑执行，第二天复盘回灌
3. 质量验证的核心理念：查杀分离
   • 类比机器学习：训练集与验证集必须分离
   • 类比业务安全：发现问题的“查”和线上处置的“杀”需要独立
   • 映射到研发质量：Development 与 Test 要形成独立验证路径
   • Test vs Review：测试通过真实执行路径验证，Review 更多依赖代码文本和经验判断
4. 事前：把需求、验收和测试策略结构化
   • /workflow:clarify：把模糊需求变成边界、风险和验收条件
   • TDD 在 Agent 时代的新定位：测试即规格，先定义“怎么算做对”
   • Agent 自写自测的风险：认知同源，容易“用训练集验证训练集”
   • 解决方向：上下文隔离、跨模型验证、属性测试、不变量测试
   • tester skill repo：从“怎么测”升级到“该测什么”
   • Push vs Pull：从过度测试转向风险驱动的恰到好处测试
5. 事中：Agent 执行，自动化测试与 Hooks 盯防
   • 按 plan.yaml 分 stage 执行：实现、验证、失败重试、提交
   • Hooks / linter / auto review：把确定性问题前移到执行过程中
   • lobbytest / ugctest：游戏后端集成测试的实践样本
   • 从 CLI 工具到插件化，再到服务化架构
   • 真实服务、模拟客户端、TraceID、日志分析共同支撑事中验证
   • 事中困惑：用例维护成本、并发测试资源、复杂场景定位成本
6. 事后：Review、Issue 与 Skill Evaluator 沉淀闭环
   • Review 放到 MR：沉淀代码上下文、判断依据和处理结果
   • Test 放到 Issue：沉淀验收标准、失败案例和回归入口
   • 高频问题回灌为 Hook、Linter、Skill、Workflow
   • Skill Evaluator：验证对象从代码升级到流程本身
   • 两类评估：Skill 是否被正确触发，Skill 是否完成预期任务
7. 开发自测的三阶段价值定位
   • 阶段一：手工测试最佳实践沉淀为可执行用例
   • 阶段二：风险评估驱动低风险变更直发
   • 阶段三：测试团队主导质量系统化，开发团队提供技术支撑
   • 风险模型：风险等级 = 失效影响 × 失效可能性
   • 低风险 + 集成测试通过，可以进入更轻量发布路径
8. 效率飞轮：从质量验证到工程资产复利
   • 事前：clarify、TDD、tester skill 定义清楚输入
   • 事中：Agent、Hooks、lobbytest / ugctest 自动执行验证
   • 事后：MR、Issue、Skill Evaluator 沉淀判断并回灌
   • 观测指标：MR 评论数、重复评论占比、Harness 回灌率、自动放行率、事前澄清耗时
9. 结语：让人的判断越来越值钱
   • 人负责业务边界、风险判断和质量标准
   • Agent 负责执行、验证、修复和重复性反馈处理
   • Harness 的价值不是让 Agent 一次写得更快，而是让团队越跑越稳、同类问题越来越少、质量资产越来越厚。

这样的技术在实践过程中有哪些痛点？

• token消耗较大，会有一定认知成本和管理成本的压力。

听众收益

1. 了解 token maxxing 的上限边界，掌握通过认知管控提升该上限的方法。
2. 明晰 vibe coding 的质量保障路径，该路径并非局限于常规的 tdd、单元测试、接口测试，而是要实现功能覆盖度与维护 ROI 的平衡。
3. 如果组织选择不缩减HC，以及保证相对稳定的组织架构的形态下，如何借力 AI 实现效能 ROI 的收益。

在运营自动化、数据分析、Coding 与办公等核心场景中，企业智能体真正面临的挑战并不是“能否调用大模型”，而是如何在复杂数据、真实系统、长链路流程和安全边界下，持续产出可验证、可治理、可复用的结果。许多 Agent 在 Demo 阶段表现良好，但进入生产后常因上下文不完整、工具调用不稳定、结果难以评估、任务中断无法恢复、模型升级引发效果回退等问题，难以形成规模化价值。

本次分享将结合企业级运营自动化 Agent、数据分析 Agent、Coding Agent 与办公智能体平台建设实践，介绍如何围绕不同场景构建 Harness：通过数据基建、知识库建设提供可信上下文；通过开发基建、CI/CD、工作流编排和沙箱机制约束执行过程；通过大模型网关实现多模型适配和成本治理；通过 Langfuse 可观测、质检和评测体系建立“执行—验证—反馈—优化”闭环；并通过数据安全、网络安全、权限控制与审计机制保障智能体在企业环境中可控运行。

演讲提纲

1. 企业级 Agent 落地背景：四类核心场景为什么都需要 Harness
   • 团队建设运营自动化、数据分析、Coding 与办公智能体的背景
   • 四类场景的共性：都从“生成内容”走向“连接数据、工具、流程和真实业务系统”
   • 共同挑战：上下文管理、工具调用、权限管理、持续迭代、测评质检
2. 四类场景的harness实践
   • 运营自动化：企业级工作流平台建设和评测质检
   • 数据分析：业务商分能力沉淀和通用分析Agent建设和成本治理
   • coding：端到端研发自动化平台建设和基建改造
   • 企业办公智能体：企业级龙虾平台建设和安全治理
3. 当前落地成果
   • 万PD级年化提效成果和典型运营自动化案例展示
   • 复杂业务商分常态化分析和成本治理
   • 技术需求和业务需求场景下研发端到端规模化落地案例
   • 企业级龙虾平台建设和使用案例
4. 实践总结和未来展望
   • 实践总结：四类场景沉淀出的企业级 Harness 方法
   • 未来展望：从场景 Agent 到企业智能体运行体系

这样的技术在实践过程中有哪些痛点？

1. 模型能力与真实业务任务之间存在断层
2. 上下文、知识和数据很难真正可用
3. Agent 调用真实系统后，执行风险显著上升
4. 缺少端到端可观测，问题难以定位和运营

听众收益

1. 获得四类企业核心场景的 Harness 建设方法：了解运营自动化、数据分析、Coding 与办公智能体在上下文、工具调用、工作流、验证和权限治理上的差异化设计。
2. 掌握 Agent 从 Demo 走向生产的关键工程能力：学习如何通过数据与知识基建、CI/CD、模型网关、Langfuse 可观测、评测质检和安全治理，让 Agent 持续稳定交付真实业务结果。
3. 借鉴多场景规模化落地的实践经验：获得关于成本治理、效果评估、模型升级回退、工具调用失控、数据权限与安全防护等真实问题的处理思路。

随着大模型能力的快速提升，越来越多企业开始尝试将 AI 引入业务流程。然而在实际落地过程中，大部分企业面临着同样的问题：模型能力很强，但业务价值难以稳定释放。数据显示，超过 80% 的企业 AI 项目停留在 PoC 或局部试点阶段，难以进入生产环境。其核心原因并非模型能力不足，而是缺少一套能够连接业务目标、企业知识、业务系统和执行流程的 Agent 执行体系。

本次分享将结合实践经验，探讨如何将“不可控的大模型”转化为“可控的Agent执行系统”。我们提出了一套基于 Business Translation（业务翻译）、Knowledge Engine（知识引擎）、Skill Framework（技能体系）和 Agent Runtime（执行引擎）的企业级 Agent Infra 架构，将业务目标逐层拆解为可执行任务，通过 MCP 协议连接企业 ERP、CRM、MES、OA 等系统，并引入 Human-in-the-Loop、人机协同审批、可观测 Trace、长期记忆和 SOP 约束机制，实现 Agent 的可控执行与持续优化。

分享中还将介绍在行业项目实践中，该架构帮助企业将原本需要数小时的数据分析与决策流程缩短至分钟级，运营分析效率提升 70% 以上，Agent 任务成功率提升超过 30%，显著提升了企业 AI 项目的生产化落地能力。

本次分享希望回答一个关键问题：在 Agent 时代，企业真正需要的并不是更大的模型，而是一套能够持续创造业务价值的 AI 执行系统。

演讲大纲

1. 问题背景：为什么企业Agent难以规模化落地
   • 行业现状：大模型能力快速提升；Agent成为企业AI落地热点；大量项目停留在PoC阶段。
   • 核心矛盾：模型能力增强 ≠ 业务价值提升；Demo效果 ≠ 生产系统能力。
   • 四大关键问题：① 知识孤岛：企业知识无法统一利用；② 系统孤岛：ERP / CRM / MES / OA无法打通；③ Agent不可控：幻觉 / 越权 / 执行错误 ；④ ROI不可衡量：无法证明业务价值 。
2. 核心观点：从模型能力到执行系统
   • 核心判断：企业需要的不是模型，而是AI Execution System（执行系统） 
   • 能力演进路径：Chat → Copilot → Workflow → Agent → Execution System 
   • 关键变化：
     • 从“生成内容”走向“执行任务”
     • 从“模型中心”走向“系统中心” 
3. 企业级Agent Infra架构设计
   • 总体架构：Business Translation；Knowledge Engine；Skill Framework；Agent Runtime；Enterprise Systems（ERP/CRM/MES/OA）
   • Business Translation（业务翻译层）：
     • 将业务目标转化为Agent可执行任务
     • Job → Task → Action拆解机制
     • 解决“业务语言不可执行”的问题 
   • Knowledge Engine（知识引擎）
     • 企业知识来源：文档 / 数据库 / 系统 / 外部数据
     • 核心能力：Chunk / Embedding / Hybrid Search / Rerank
     • 关键问题：知识治理而非单纯RAG 
   • Skill Framework（技能体系）：Tool → Skill → Workflow抽象；解决工具碎片化问题；支撑复用、权限与治理 
   • Agent Runtime（执行引擎）：Planning / Reasoning / Memory / Execution；多Agent协同机制；长任务执行与状态管理；失败恢复与重试机制 
4. Agent可控性设计：从“能用”到“可控”
   •  Human-in-the-Loop：关键节点人工介入；风险控制与确认机制 
   • SOP约束机制：将企业流程固化为执行规则；限制Agent自由发挥空间 
   • Trace可观测体系：思考过程可视化；Tool调用链路追踪；执行过程审计 
   • Agent治理体系：权限控制；审计机制；回滚与风控 
5. 企业级Agent实践案例
   • 进出口报关Agent
     • 业务效果：从3小时 → 10分钟，效率提升70%+ 
     • Agent实现路径：业务翻译(业务专家负责)->skill开发&Agent调度（技术专家负责）->Agent执行（运营专家负责）
   • 广告投放Agent
     • 业务效果：从半天 → 30分钟 
     • 人和Agent协作路径：Agent执行、人来拍板，行业/客户的需求变化如何快速调整运维
6. 总结与展望
   • 核心结论：大模型决定能力上限；执行系统决定业务价值 
   • 行业趋势：从模型竞争 → 系统竞争；从工具使用 → 执行体系构建 
   • 最终观点：企业真正需要的不是一个会聊天的大模型，而是一套能够持续创造业务价值的AI执行系统

这样的技术在实践过程中有哪些痛点？

1. Agent任务成功率难以保证企业任务往往涉及多步骤推理、多系统协同和长链路执行。随着任务长度增加，模型容易出现目标漂移、上下文遗忘和执行失败等问题，导致任务完成率快速下降。
2. 企业知识利用率低很多企业已经建设了知识库，但实际效果并不理想。问题往往不在于 RAG 本身，而在于知识治理体系缺失，包括知识清洗、切片、标签体系和知识质量评估机制不足。
3. Agent执行不可控企业无法接受“差不多正确”的结果。如何通过 SOP 约束、人机审批、权限体系、执行审计以及全链路 Trace，让 Agent 从“会思考”走向“可执行、可治理”，是落地过程中的关键挑战。
4. 企业系统集成复杂Agent 要真正创造价值，必须连接 ERP、CRM、MES、OA 等核心系统。权限管理、接口稳定性、异常恢复、长链路事务处理等问题远比模型推理本身更加复杂。

听众收益

1. 对于架构师和技术负责人：
   • 理解企业级Agent落地的整体架构设计
   • 掌握Agent Runtime与Agent Governance 的关键设计思路
2. 对于Agent工程师：
   • 学习Business Translation、Knowledge Engine、Skill Framework等核心架构设计
   • 掌握多Agent协同与长任务执行的实现方法
   • 理解Agent 可观测性与可控性建设路径
3. 对于企业数字化负责人和CTO：
   • 了解企业Agent项目为什么难以规模化落地
   • 学习如何构建企业级 AI 执行系统
   • 掌握衡量 Agent ROI 和业务价值的方法论

把 AI Agent 接入企业系统时，主流做法是堆 RAG 或把数据塞进上下文。但可观测数据天然是分散的指标、日志、拓扑、变更——Agent 拿到的是碎片，回答不了“谁影响了谁”“为什么慢”“这次故障谁的锅”。本质问题不是数据不够，而是数据没有“意义”。

本次分享提出一条不同路线：先建一层可观测对象图语义层，把实体、关系、拓扑、指标、日志统一成 Agent 能查询、能多跳推理的上下文，并讲清它与 OpenTelemetry / Prometheus / CMDB 是补充而非替代。技术上覆盖三块：统一的 SPL 查询面（一套契约同时服务人、CLI、Web、REST 与 AI Agent）；通过 MCP 把对象图安全暴露给 Agent；以及专为 Agent 设计的 plan/data 查询契约与紧凑响应信封。

演讲提纲

1. 为什么“更多数据 / 更大模型”解决不了 Agent 的可观测问题（含踩坑）
   • 三种常见失败模式：直接把日志/指标塞进上下文、纯向量 RAG、给 Agent 开一堆领域专用 API
   • 踩坑实录：碎片化导致 Agent 看不到关系、token 爆炸、关系靠 LLM 脑补产生幻觉根因
   • 结论：缺的不是数据量，是“对象图 + 关系语义”这一层
2. 对象图语义层怎么建
   • 核心对象：EntitySet（对象类型）、关系/拓扑、数据集（指标/日志/事件）、存储与字段映射
   • 一套 SPL 查询面（.umodel / .entity / .topo / entity-call）同时服务人和 AI——为什么坚持“单一读取面”而不是领域专用 API
   • 与 OTel / Prometheus / CMDB 的映射姿势：补充而非替代
3. 把对象图接给 AI Agent
   • MCP 工具/资源面设计：默认只读、写操作默认关闭的安全边界
   • plan vs data 范式：开源侧只产出“查询计划”，把执行留给下游 executor，为什么这么设计
   • 踩坑：给人用的响应信封对 Agent 不友好（双层 JSON 嵌套、噪声字段占 ~85% token），如何重做出 ?format=agent 紧凑信封——上下文体积压缩约数倍
4. 真实场景：Agent 走一遍故障定位（开源 demo）
   • 定位 degraded 服务 → 拉自身指标/日志 → 加载 Runbook → 查上游变更 → 排除“红鲱鱼”无关发布 → 跨域发现促销流量放大 → 关联出根因并给建议
   • 关键设计：Runbook 引导的结构化诊断 vs Agent 自由发挥；为什么故意埋一个“看似元凶”的干扰项
5. 落地 tradeoff 与开源共建
   • 建模成本、语义层维护、与现有可观测栈的边界
   • 开源路线：GraphStore Provider / Domain Profile / 一致性验证的共建入口

这样的技术在实践过程中有哪些痛点？

• 前期建模有成本，不是开箱即得：要把“藏在人脑里的系统知识”（谁调用谁、变更影响哪些服务）显式建模出来，初期投入不小。
• 语义层会 rot：对象图必须跟系统演进同步维护，否则会和现实漂移，反而误导 Agent——这是长期维护负担。
• 价值强依赖关系数据质量：关系缺失或错误会让多跳推理走偏；对象图放大了“关系正确性”的重要性。
• 不是银弹：它解决“上下文结构与可推理性”，不解决底层采集质量；与现有可观测栈是补充关系，不能替代。
• plan/data 分离的代价：灵活性换来的是——纯开源侧拿到的是查询计划而非数据，真正取数需要下游 executor 承接。
• 要维护“两套表达”：给人看的响应和给 Agent 看的紧凑信封需要分别设计，多一份契约维护成本。

听众收益

• 一套可复用方法论：如何把分散的指标/日志/拓扑/变更组织成 AI 能推理的对象图语义层，而不是无脑堆 RAG 或换更大的模型——附判断“该不该建、怎么建”的决策依据。
• 面向 Agent 的 API / 契约设计经验：plan vs data 范式、把上下文 token 成本压缩约数倍的响应信封设计，可直接迁移到自己的 Agent 平台。
• 一个开源可复现的 AI 故障定位范式 + 诚实的 tradeoff 清单，帮助技术决策者少踩坑、看清边界。

操作系统正在经历从被动「App 容器」到主动「Agent 调度中心」的代际革命。本次分享将介绍荣耀 YOYO 智能体平台 AgenticOS 的核心架构与技术实践——AgenticOS 以意图驱动为核心，通过五层重构架构（硬件抽象→AI 内核→大模型矩阵→Agent 框架→生态层）、LOOP 自循环机制、四类模型矩阵与端云协同，实现用户只需表达意图、系统自主完成跨应用跨设备全链路任务。

演讲提纲

1. AgenticOS 总览 — 代际革命定位、四大核心特性、五层架构全景
2. Agent 框架与调度 — 多智能体协同（3 种模式）、LOOP 自循环、认知记忆（记/学/用）
3. 大模型矩阵与 SOTA — 端侧模型、Auto Action 界面领航员、MobileWorld / MMBench 双榜登顶
4. AI 内核与底层架构 — OrchBoost 异构调度、内存精细管理、权限沙箱、硬件抽象层
5. 发展路线图 + 总结 — 落地时间线、五大核心 Takeaway、Q&A

实践痛点：

1. 设备孤岛：App 之间互不通信，用户在多应用间反复切换，OS 仅充当被动的图标容器
2. 生态割裂：不同芯片平台、不同设备形态（手机/平板/PC/手表/眼镜）各自为政，开发适配成本极高
3. Agent 缺乏持续思考能力：大多数 AI 助手「问一句答一句」，做完即忘，无法沉淀经验越用越聪明
4. 多 Agent 协作黑盒：复杂任务需要多 Agent 协同，但缺乏透明化的调度和分工机制，出错难以追溯
5. 任务执行僵化：传统自动化按固定脚本执行，遇到异常无法动态重规划（Replan），容错率低

听众收益：

1. 建立代际认知：理解 OS 从「容器」到「调度中心」的范式转移，看清产业方向
2. 学会 Agent 设计范式：多智能体三种协同模式、LOOP 自循环、认知记忆「记/学/用」可迁移到自建 Agent 系统
3. 学习端侧工程底座：OrchBoost 异构调度四步法、内存分治策略、沙箱安全、硬件抽象层设计，可直接借鉴

金融监管数据是一个“零容错、强追溯、口径复杂”的场景：一张报表背后是成百上千的指标口径、明细数据和监管规则，任何一处口径漂移或数据错误都可能带来合规风险。当我们尝试用 Agent 来承接采集、计算、检核、复核这些工作时，很快发现——决定 Agent 能否“跑得稳”的，不是模型能力，而是它背后的数据资产与知识资产质量，以及一套让二者持续相互增强的工程体系。

本次分享将先从金融监管的真实应用场景切入：从监管要求解析、数据采集处理、日常质量检核，到问题根因/血缘追溯、缺失数据补全、数据复核，看清 Agent 在每个环节要解决什么、又卡在哪里、如何解决。

演讲提纲

1. 第一部分：应用场景——Agent 在金融监管中要解决什么
   • 背景：金融监管为什么“不容 Agent 犯错”
     • 场景特点：口径复杂、频度高、零容错、强追溯。
     • 通用 Agent 直接上场的三大痛点：口径漂移、幻觉、不可解释。
   • 端到端应用场景全景
     • 需求侧：解析监管要求 + 比对内部数据情况，自动生成采集逻辑、处理程序、质量控制规则。
     • 报送中：智能数据初始化、自动质量检核。
     • 问题处置：根因分析、血缘分析、数据追溯、缺失数据智能补全。
     • 报送前：数据复核、生成复核报告、给出审核建议。
2. 第二部分：解决方案——Harness 体系如何支撑场景落地
   • AIR Harness：面向金融监管的智能体底座
     • 定位：让 Agent 在监管“零容错、强追溯”要求下稳定运行的工程底座。
     • 核心能力：Agent / Skill / Tools / MCP 创建——但都服务于“口径受控、数据可查、逻辑可溯”。
     • 监管特性一 · 口径受控执行：Agent 依据已治理的知识/数据资产执行，取数逻辑与指标计算被“钉”在治理成果上；高频监管场景（指标计算、报表勾稽校验）固化为标准 Skill。
     • 监管特性二 · 面向监管数据形态的受控连接：MCP 精准对接明细/指标/报表库、监管知识库、勾稽血缘图库，每次取数与知识引用可审计、可留痕。
     • 监管特性三 · 全链路可追溯：记录每一步（调用哪个 Skill、引用哪条口径、取哪张表、走哪条血缘），报送结果可逐层回溯到规则与数据源。
   • 两大知识底座：让 Agent“既懂知识，又懂关系”
     • 向量知识库：基础知识部分，分类存储监管制度/口径说明/数据字典，MCP 接入增强 RAG。
     • 图数据库：关系与逻辑部分，以图存储指标勾稽、数据血缘、报送逻辑关系，MCP 接入增强 RAG。
     • 双底座如何解决“口径依赖上下文、指标依赖计算逻辑”。
   • 数据资产管理：数据即知识，知识反哺数据
     • 数据分层：明细类、指标类、报表类、非结构化。
     • 三类定义入库为知识：表/字段定义、指标口径与计算逻辑、报表口径频度范围。
     • Agent → 治理提效：自动完善元数据、识别数据标准、安全分级分类、数据确权。
     • 数据资产 → Agent 反哺：自动生成取数 SQL、取指标方法、数据知识问答。
   • 数据质量管理：Agent 驱动的质量闭环
     • 以数据资产为基础的动态监测。
     • Agent 自动生成检核规则、评估有效性。
     • 问题闭环：根因/血缘/追溯 → 处置流程 → 考核评价。
     • 自动生成质量分析报告、考核评价报告。
   • 回扣场景：双向驱动如何让前述场景稳定运行
     • Agent 按“知识资产的业务逻辑 + 数据资产的定义信息”执行，而非自由发挥。
     • Skill 固化 + MCP 受控接入：抑制幻觉、锁定口径。
     • 全链路可解释与可追溯：结果回溯到规则、数据与血缘（呼应第一部分痛点）。
3. 第三部分：经验与展望
   • 落地经验与展望
     • 双向驱动飞轮：治理越好 → Agent 越稳 → 治理更高效。
     • 踩坑与经验总结。

这样的技术在实践过程中有哪些痛点？

• 数据资产和知识资产在初步形成及后续维护过程中的质量稳定性及稳定性评价方面，还存在不可控因素。

听众收益

• 金融监管场景下 Agent 落地的全流程拆解与真实痛点。
• 一套可复用的“知识/数据资产 → Harness → Agent”工程范式。

现有很多 Agent Benchmark 主要是在测模型本身的能力，或者测模型和Harness适配的程度，但难以定位并分析Harness哪个维度的设计对结果产生了影响。

我们的核心思路是Harness组件化+错误归因：将Harness从完整Agent系统中解耦出来，拆分为执行环境、工具调用、上下文记忆、任务编排、可观测性、结果验证和安全治理等组件，并进一步细化为可以单独测试的子能力。

基于这些拆解，我们设计可复现、可自动评分的任务，并配套开发轨迹追踪和归因模块，让Benchmark不只是判断最后是否完成任务，还能分析到底是哪个Harness组件在起作用、哪里成为瓶颈。

这一方法也在招聘Agent、房产视频内容生成Agent等产业化长链路场景中持续验证：一方面用组件级评测定位真实业务中的Harness能力缺口，另一方面将业务落地中暴露的问题反哺到任务设计、轨迹分析和归因规则中，形成技术研究与产业实践的闭环。

演讲提纲

1. 为什么Agent Benchmark需要从成功率走向失败归因
   • 介绍现有Agent Benchmark的局限：很多评测能判断任务是否完成，但很难解释失败来自模型能力、Harness设计，还是模型与Harness的适配问题。进一步说明在长程任务中，执行环境、工具调用、上下文管理、验证机制等工程组件会显著影响结果。
2. 产业化长链路Agent中暴露出的Harness问题
   • 结合我们实际落地的招聘Agent、房产视频内容生成Agent等落地场景，提炼长链路Agent的共性挑战：需求澄清不充分、上下文约束丢失、工具调用结果不稳定、多阶段任务容易早停、最终结果缺少可验证证据链等。这些问题并不总是模型能力不足，而往往来自Harness在工具、上下文、编排、验证和治理等环节的能力缺口。
3. Agent Harness的组件化拆解方法
   • 介绍我们如何将Harness从完整Agent系统中解耦出来，并拆成执行环境、工具调用、上下文记忆、任务编排、可观测性、结果验证、安全治理等维度。
   • 重点说明拆解原则：组件必须可观测、可造题、可归因，且能进一步细化成单独测试的子能力。
4. 企业级Harness设计：从能力封装到可治理运行时
   • 结合组件拆解，进一步讨论企业级Harness应如何设计：它不只是模型调用外壳，而是Agent的运行时控制层，需要统一处理工具权限、上下文注入、任务编排、轨迹观测、结果验证和安全治理。
   • 结合我们在招聘Agent和房产视频内容生成Agent中的Harness设计实践，重点分析企业落地中的几个关键取舍：自主性与可控性、通用框架与业务定制、完整可观测性与运行成本之间的平衡。
5. 可归因任务如何设计：从真实问题到单组件压力测试与corner case挖掘
   • 任务设计方法：从真实长链路场景中抽象出可复现的Harness子能力问题，每道任务围绕一个主要组件构造压力源，同时控制其他因素。包括任务描述、初始workspace、隐藏verifier、评分脚本、isolation说明等模块。
   • 如何避免题目变成“大而全”的综合任务；
   • 在测评产业级Harness时的迭代机制：通过Benchmark持续暴露真实业务中的corner case，将失败样本、边界输入、异常工具返回和长链路中断等问题沉淀为新的测试任务，再反向推动Harness在工具协议、上下文管理、任务编排和验证闭环上的优化。
6. 轨迹追踪模块：让Benchmark看见过程而不只看结果
   • 介绍轨迹追踪模块如何记录模型输入、工具调用、工具结果、文件修改、命令执行、最终回答和失败状态。说明为什么只有final answer不足以做归因，必须结合执行轨迹判断Agent是否走了错误路径、跳过验证、误用工具或被上下文污染。
7. 错误归因模块：把失败映射回Harness组件
   • 结合典型失败模式说明如何将失败归因到具体Harness维度，例如工具schema理解错误、上下文检索不充分、任务早停、验证证据不足、沙箱边界失效、安全策略绕过等。重点讲归因规则、隐藏检查项和trace证据如何结合。
8. 实践踩坑：可复现、可评分、可归因之间的取舍
   • 分享任务构造和评测框架开发中的关键问题：单组件隔离难、verifier设计容易过窄、真实Harness的trace格式不统一、过强规则可能降低任务真实性、过程评分与最终评分可能不一致等。
9. 后续演进：从组件评测到数据-模型-应用闭环
   • 展望完整题库扩充后，如何形成组件能力画像、Harness框架对比、成本与可靠性分析，并帮助团队判断应该优先优化工具层、上下文层、验证闭环还是安全治理能力。进一步讨论如何从真实业务Agent的轨迹和失败案例中沉淀高质量任务、过程监督信号和修复路径，探索面向AGI的数据合成范式。

这样的技术在实践过程中有哪些痛点？

1. 组件隔离与真实复杂度之间存在天然冲突
   • 如果任务设计过于纯粹，归因会更清晰，但可能脱离真实业务；如果任务过于贴近招聘Agent、房产视频内容生成Agent这类长链路场景，又很容易变成多组件耦合，难以判断到底是哪一层Harness起作用。
2. 真实业务中的失败往往是多组件耦合问题
   • 产业级Harness的失败很少是单点问题，可能同时来自需求澄清不充分、上下文约束丢失、工具返回异常、任务编排早停、结果验证缺失等多个环节。因此错误归因不能只看final answer，需要结合任务设计、隐藏检查项和执行轨迹共同判断。
3. 自动评分的确定性和业务语义覆盖难以兼得
   • 程序化verifier可复现、成本低、稳定性强，但容易只覆盖显式结果；而招聘匹配质量、内容生成质量、业务表达准确性等问题往往带有语义判断，需要引入更复杂的规则、人工评审或LLM judge，这又会带来不稳定性和评审偏差。
4. Trace标准化和可观测性建设成本很高
   • 不同Agent Harness暴露的轨迹粒度不同，有的能完整记录tool call、文件修改和中间状态，有的只能从日志、session文件或最终输出中恢复过程。要做稳定归因，必须先解决trace格式统一、关键事件抽取、隐私脱敏和存储成本问题。
5. 持续挖掘corner case会带来Benchmark维护压力
   • 在测评产业级Harness时，Benchmark会不断暴露新的边界输入、异常工具返回、长链路中断和业务规则冲突。这些case很有价值，但如果缺少分层管理、版本控制和回归机制，题库会越来越难维护，也可能导致Harness过度适配某一批测试任务。
6. 更强的Harness往往意味着更高成本
   • 增加验证轮次、上下文压缩、工具保护、安全审计、人工确认和失败重试机制可以提升可靠性，但也会带来token成本、执行时延、系统复杂度和用户体验成本。企业落地时必须在可靠性、效率、成本和可控性之间做取舍。

听众收益

1. 获得一套可复用的Agent可靠性诊断方法
   • 从pass/fail进一步定位到上下文、工具、沙箱、验证、可观测、安全治理等Harness组件，帮助团队把“Agent为什么没做好”拆解成可分析、可优化的工程问题。
2. 学会如何设计可归因的Agent Benchmark
   • 结合招聘、房产视频内容生成等场景，理解如何从真实长链路Agent场景中抽象评测任务，设计单瓶颈任务、隐藏verifier、isolation预注册、trace replay和失败分类机制，让Benchmark不只用于排名，也能用于诊断和迭代。
3. 获得企业级Harness落地的设计参考
   • 结合招聘、房产视频内容生成等场景，理解企业级Harness在工具权限、上下文工程、任务编排、验证闭环、可观测与安全审计之间的关键取舍，并判断团队应该优先补哪一层能力。
4. 理解面向AGI的高质量数据合成思路
   • 学习如何从真实业务Agent的失败轨迹、corner case和修复路径中提炼可验证任务、过程监督信号和能力边界标注，为后续模型训练、Agent对齐与“数据-模型-应用”闭环提供更高质量的数据来源。