Agent 上岗之后，企业如何治理硅基团队？

6 月 26 日，“AI 原生·聚变新生”2026 张江人工智能创新小镇生态日在上海张江举行。作为生态日五场平行论坛之一，由张江人工智能创新小镇联合 InfoQ 极客邦传媒共同举办的 Top Tower Talk「Harness 时代的硅基团队治理」专场，在张江科学之门 A 塔 67 层圆满举行。 本场活动聚焦一个正在从概念走向现实的问题：当 AI Agent 从个人效率工具，进一步进入企业研发、运营、数据分析、业务交付等核心流程之后，企业如何让它真正“听话”又“懂行”？换句话说，Agent 已经不只是一个可以调用的大模型接口，而正在成为一种新的生产力单元。它能写代码、做调研、生成报告、调用工具、参与决策，也可能在长任务中反复试错、误用工具、丢失上下文，甚至把错误经验沉淀进组织流程。 因此，企业今天需要讨论的已经不是“要不要用 Agent”，而是如何为 Agent 建立一套可控、可信、可追责、可持续进化的 Harness 系统。 本场论坛以两场主题分享打开讨论。质变科技 MemoryLake 首席架构师周祥聚焦 Agent 的长期记忆工程，讨论企业如何将上下文、经验与知识沉淀为可复用的记忆资产；华为 2012 实验室项目群总监董鑫则从大型研发团队实践出发，分享 AI 进入研发主流程后，组织协作方式正在发生的变化。在随后的圆桌环节，两位分享嘉宾与 Toco 创始人兼 CE 时很快会遇到的现实问题。周祥提到，过去企业更熟悉 DevOps、CI/CD、应用集成和数据集成，而当智能体真正上线之后，一个更直接的问题出现了：它一个月到底会消耗多少 Token？如果 Agent 在执行任务时上下文不完整、Skill 调用不准确，或者工具选择不精准，就可能陷入大量 retry 和 fail over。任务表面上完成了，但背后已经发生了高额的试错成本。 让 Agent 拥有长期记忆 周祥的分享从一个基础判断切入：智能不只是“思考力”，还包括“记忆力”。前者由基础大模型承载，涵盖训练、推理、生成和理解；后者则关乎数据如何被提取、积累、进化和沉淀。换句话说，模型决定 Agent 当下能做什么，记忆则决定它能否在一次次任务中持续进化。 这也是企业落地 Agent 时很快会遇到的现实问题。周祥提到，过去企业更熟悉 DevOps、CI/CD、应用集成和数据集成，而当智能体真正上线之后，一个更直接的问题出现了：它一个月到底会消耗多少 Token？如果 Agent 在执行任务时上下文不完整、Skill 调用不准确，或者工具选择不精准，就可能陷入大量 retry 和 fail over。任务表面上完成了，但背后已经发生了高额的试错成本。 因此，Token 的真实成本不能只看单价，还要看任务成功率。按照周祥 PPT 中给出的公式，Token 成本等于 Token 单价除以任务成功率。成功率越低，实际成本越高；一次做对的概率越高，企业为无效试错支付的成本就越少。由此看，记忆工程并不是锦上添花，而是 Agent 进入生产环境后必须补上的一层基础能力。 但现实中，企业的记忆基础设施往往并不统一。数据库、数仓、知识库 RAG、会话记忆系统各自存在，个人用户用起来割裂，企业侧则要面对多系统融合和架构演进的复杂性。周祥介绍，MemoryLake 试图将这些分散能力整合为一体化的记忆与 Agent 平台，让企业既有系统、结构化数据、半结构化数据和多模态文件都能接入同一个记忆底座。 围绕这一目标，他将记忆系统拆解为三类核心能力：记忆蒸馏、记忆计算和记忆堆叠。 记忆蒸馏解决的是“知识如何变成可用记忆”。企业中的大量经验并不天然适合 Agent 调用，它们分散在文本、邮件、聊天记录、PDF、表格、图片、音视频、数据库、业务文档、SOP 和流程规则中。周祥提到，MemoryLake 通过 D1 小模型进行多模态数据提取，将复杂表格等内容转化为结构化 JSON、多模态索引、决策图谱、业务知识等记忆资产。在复杂表格提取场景中，相关准确率从小于 70% 提升到 99.8%。 记忆计算进一步解决“记忆如何参与推理”。这其中包括冲突检测、遗忘、合并、演进，以及时间一致性、跨会话综合、抗幻觉和语义模糊等问题。比如，同一事项在不同文档中可能出现相对时间与绝对时间的混用，系统不能只做简单检索，而要把这些信息放进统一的时间轴和语境中重新理解。 记忆堆叠则更接近企业落地中的治理问题。企业需要沉淀优秀员工的最佳实践和高质量 Skill，让新人和 Agent 能够复用；同时也必须隔离低质量经验、个人偏见和错误模式，避免它们进入组织共享记忆池。换句话说，组织记忆不能只是“把所有人的经验都存下来”，而要有筛选、隔离、归属和审批机制。 这也引出了周祥分享中最关键的组织级框架：Workspace、Actor 和 Project。Workspace 是承载项目、协作关系和上下文的大容器；Actor 可以是人，也可以是 Agent；Project 则用于组织文档库、数据库、开放数据集、会话、记忆条目和 Skills 等资产。在这一框架下，记忆读取可以跨 Project 发生，但写入必须落到明确的主 Project 和 Actor 之下。这样一来，多 Agent 协作、Human-Agent 协作和组织记忆沉淀之间，才能形成更清晰的读写边界和责任归属。 AI 研发下半场的组织进化 如果说长在个人级任务上，AI 的提效已经非常明显。董鑫举例，一个编译器 Crash 问题，工程师自己排查了三四天没有解决，后来借助 AI 半个上午就完成定位和修复。但进入团队级场景后，情况并没有这么简单。真实研发组织不是许多个体效率的简单相加。一线研发人员真正写代码的时间可能只有约 20%，大量时间都消耗在需求对齐、测试、会议、责任边界和跨团队沟通上。 因此，AI 研发下半场的关键，不只是让每个工程师都用上 AI，而是让 Agent 能够在团队流程中自己转起来。董鑫在分享中特别强调了 Human on the Loop 与 Human in the Loop：前者意味着人在系统上方做治理，制定规则、观察状态、控制边界，保障系统可控；后者意味着人在必要节点进入流程，对异常、分歧和高风险结果进行判断与干预，保障结果可信。 基于这一思路，团队构建了 ACE Harness 系统。该系统面向仓颉编程语言等开源代码场景，可以让 Agent 自动分析社区 Issue、复现问题、定位根因、生成报告，并把任务分配给需要处理的人。在这一过程中，Agent 并不是单点执行，而是以团队形式协作：有 Agent 负责定位问题，有“蓝军”Agent 负责反向审视和挑战，也有“裁判”Agent 在分歧出现时进行仲裁；如果需要人工介入，整个 Loop 会暂停，等待工程师处理。据董鑫介绍，这套系统 7×24 小时运行，在相关流程上带来了约 50% 到 1 倍的效率提升。 当 Agent 能够持续运转，组织调度方式也要随之变化。董鑫介绍，团队尝试了 ATM（Ability-based Task Matching）机制，根据任务所需能力，在人和 Agent 之间进行动态匹配。过去，一个固定小组负责固定范围内的工在这里更像研究者的加速器，适合