HJ | 杭建修改

2026-09-17 21:54:25

代码写得更快了，需求为什么还在排队？

这可能是企业引入 AI 编码工具后，最值得追问的问题。

工程师可以很快生成一段实现，但产品口径尚未确定；Agent 已经完成修改，却不了解另一个服务的隐含依赖；测试全部通过，上线后才发现验收标准漏掉了关键场景。

编码速度的提升是真实的，交付流程中的等待、返工和协作成本也是真实的。当一个环节加速，原来被它掩盖的问题就会显现。

最近看了一些企业 AI-Native 实践分享，也与正在推进转型的 CTO、技术负责人交流，我越来越关注一个问题：怎样把个人使用 AI 的能力，变成团队能够持续复用的交付能力？

一. 什么叫 AI-Native？

在我看来，AI-Native 体现为产品、组织和认知方式的变化。是否使用 AI 工具、年龄多大，都不足以判断一个人或一家企业是否具备这种思维。

第一，产品探索从模型能力边界出发。 先通过实际使用与测试，摸清模型已经能稳定完成什么、哪些能力仍不可靠，再探索由此成为可能的产品形态。对未来能力可以作假设，但需要持续验证。这并不意味着忽略用户需求，而是让技术能力参与定义产品机会，再由真实用户价值检验方向。模型成为产品设计的基础，也就有机会改变整个工作流。

第二，组织围绕人与 Agent 的组合分工。 面对一组任务，先考虑哪些判断由人承担，哪些执行可以交给 Agent，怎样验收、何时升级，再决定岗位与协作方式。一个人可以协调多个 Agent，承担更完整的交付责任。组织设计的重点随之转向任务、能力、权限与责任之间的匹配。

第三，用一手信息和亲自验证形成判断。 论文、模型卡、官方文档、代码仓库中的问题讨论，以及自己运行的评测，应成为判断能力边界的重要依据。行业分享与交流可以提供线索，但关键结论要回到原始材料，并在自己的任务上验证。特别是决定采用什么模型、开放多大执行范围时，实测结果应当比转述更有分量。

这三点也构成了我理解企业落地的起点：产品围绕模型能力探索，组织围绕人机协作重构，判断依靠一手证据校准。 后文的 Agent Readable，则是把这种思维落实为工程能力的一项基础：让任务、知识、工具与验收规则真正能够被 Agent 使用。

二. 企业 AI-Native 的两条落地线

在企业内部，我倾向于把 AI-Native 分成两部分：AI-Native 产研与Agentic 业务与职能。

AI-Native 产研，也就是 Vibe Coding 的工程化。 它面向研发交付，关注需求如何变成 Spec，代码库如何被 Agent 理解，代码生成、测试、评审和发布如何形成可追踪的链路。它的结果是更稳定的产品迭代能力，而不只是更快地写出代码。

Agentic 业务与职能。 它面向数据分析、客服、运营、销售、测试等具体工作，关注业务系统能力如何通过 MCP 或 CLI 暴露，岗位流程如何沉淀为 Skill，Agent 如何进入已有协作场景，并在权限范围内完成任务、提交结果和请求人工介入。

两条线的用户和交付物不同，但底座应当共享：模型接入与 Token 治理提供资源和度量，Agent Readable 提供代码、数据和业务上下文，权限与审计提供边界，测试和评审提供验证，知识治理负责把有效经验沉淀下来。

可以把它理解成同一套企业 AI 能力的两个出口：产研线把能力用于“构建和维护产品”，业务线把能力用于“运行和改善业务”。如果只做 Vibe Coding，企业可能获得更快的研发，却仍让业务流程依赖人工传递；如果只做业务 Agent，缺少工程化底座又容易出现权限不清、知识过期和结果不可复核。两条线应分别试点、共享底座，再通过统一指标比较实际交付价值。

三. 从认知到落地

结合团队落地经验，本文尝试给出一条工程落地路径：以 Token 治理保障接入与度量，明确意图与责任，建设 Agent 可理解的上下文，随后把执行、验证和异常处理接成闭环，最后让有效经验在团队中积累。

文中的实践经过匿名化整理，保留建设方法与阶段性经验，不涉及具体企业、产品及实施排期。案例中的阶段状态描述的是相应实践过程，不代表当前部署情况。

这张图表达的是时间上的演进路线：企业通常先解决接入和投入可见性，再把任务意图说清楚，接着建设 Agent 可理解的上下文，最后把有效做法沉淀为团队可以复用的能力。它不是严格的瀑布流程，试点中几项能力往往会并行建设，但成熟度大致沿着这个方向推进。

如果把问题换成“这些能力最终由什么承载”，需要看另一张图。下面的架构图表达的是空间上的分层关系：上层是 AI-Native 产研和 Agentic 业务与职能两条落地线，中间是 Agent 能力层与 Runtime，底层是模型接入、Token、企业数据、知识和系统资源。箭头表示能力依赖，不表示项目必须按自下而上的单线顺序交付。

两张图合起来，分别回答“能力如何逐步成熟”和“成熟后的能力如何被组织承载”。不同业务、不同风险等级的任务，可以在同一架构上长期采用不同程度的自动化。

四. Token 治理：让团队用得上、看得清、持续改进

企业推进 AI，往往先从工具采购、模型接入和账号分配开始。这些工作必要，但它们回答的是“能不能用”，还没有回答“用得是否有效”。

如果把 Token 消耗、AI 生成代码占比或 PR 数量直接作为成绩，团队很容易优化出更多调用、更多代码和更多提交，却没有缩短一次需求真正交付的时间。

Token 是投入，经过验收的交付才是产出。

试点开始前，建议先记录几项基线：

比较时应尽量保持任务类型、复杂度和验收口径一致。一个简单页面与一次跨服务数据迁移，不能因为都算“一项任务”，就直接比较完成速度。

自主完成率也需要定义清楚。例如，统计范围是“无需中途人工纠偏，达到 PR 待审状态的任务”，就不能把这个指标解释成“无需人工即可上线”。

接入治理实践：从统一入口到成本归集

在一个团队的落地实践中，Token 治理是一条独立的建设主线。第一批工作集中在三个问题：员工怎样接入，资源怎样管理，投入怎样衡量。

该案例首先完成了几项基础建设：

• 统一接入：验证 Coding Agent 与统一 API 入口的兼容性，搭建供团队使用的模型调用网关。
• 订阅资源管理：将分散的订阅账号和接入资源纳入统一管理，明确资源归属与使用范围。
• 降低配置门槛：提供一键配置脚本和安装包，让非研发用户也能快速完成工具与模型入口的配置。
• 建设管理视图：扩展统一管理平台，覆盖部门、业务、项目组织管理，分业务成本统计，以及调用质量分析。

这些工作解决的是规模化使用的前提：团队成员不用各自摸索配置，平台能够识别调用属于哪个业务，也能把投入放到同一口径下观察。具体资源组织方式可以根据接入条件选择，重点是让企业订阅和 API 配额的归属、用量及费用可追踪。

成本、使用率与质量，要放在一起看

在这类实践中，可以先手工汇总订阅与 API 费用，再推进平台自动统计，并将代码产出与费用关联观察。

这个指标可以帮助建立投入产出的初步视图，但还不能单独证明业务价值。如果采用代码当量，计算规则需要固定，生成代码是否被采纳、是否通过验收，以及审核和返工花了多少时间，也需要一起观察。

在基础统计之上，还可以按团队或任务类型分析使用覆盖、提示词质量和重复调用，帮助发现配置、上下文与流程中的问题。

我的理解是，Token 治理可以逐步形成三个视角：

例如，某类任务消耗很高时，应进一步区分：是任务本身复杂、重复传入大量上下文，还是需求不清导致反复重试？低使用率也需要区分：是没有适用场景，还是配置和工作流挡住了用户？热力图提供线索，任务结果才帮助我们判断原因。

下一步值得建设的是把调用记录与任务、PR、文档或测试报告关联起来，逐渐从“花了多少 Token”走到“完成一个合格任务花了多少总成本”。这也是 Token 治理与研发工程化真正接上的地方。

组织上的前提同样重要：负责人需要明确试点目标，允许团队投入时间建设规范、测试和知识资产，并安排人处理跨团队依赖。否则，一线工程师节省出来的编码时间，仍会消耗在旧流程的等待中。

五. 用 Spec 明确意图，也明确人的责任

当 AI 承担越来越多执行工作，需求表达中的歧义会直接影响产物。

“给客户分析增加一个导出功能”看起来很明确，真正实现时却会遇到一系列问题：谁有权导出？导出哪些字段？时间范围如何解释？是否包含敏感信息？大数据量如何处理？失败后能否重试？

这些问题需要业务和工程共同作出判断。AI 可以帮助发现遗漏、比较方案、起草规格，但不能凭空获得业务授权。

Spec 的价值，就在于把这些决定变成可追溯、可检查的交付依据。

一份可用于执行的 Spec，至少应包含：

• 目标与非目标：本次解决什么问题，哪些内容明确不做。
• 业务规则：术语、指标口径、权限和异常场景。
• 工程约束：接口兼容性、依赖关系、性能及数据边界。
• 验收标准：什么证据能够证明任务完成。
• 待决事项：哪些问题仍需确认，由谁决定。

Spec 应与代码一起版本化。需求变化时，同步调整规格、测试与实现；执行中发现矛盾时，回到决策者确认。只有这样，Spec 才能持续发挥作用。

角色的变化，是责任向两端延伸

工程师需要更早参与需求澄清，也需要对最终验证负责。产品和设计可以借助 AI 生成原型、探索方案、验证体验，让讨论更早建立在可观察的产物上。

但“一个人能做更多事”，不等于专业判断与责任自动消失。

小团队可以由同一人承担多项职责，但每项决定仍应有明确负责人。

测试把规格变成证据

对于行为可明确验证的改动，可以先根据验收标准建立测试，确认测试能够暴露问题，再实现功能并持续回归。

这里需要注意：如果规格本身遗漏了场景，AI 生成的测试和代码可能一起遗漏。因此，测试通过证明的是已覆盖条件下的行为，业务验收还需要确认这些条件是否完整。

六. 让 Agent 读懂项目，也让上下文保持有效

到目前为止，我形成的一个判断是：AI-Native = Agent Readable。

它强调的是一种建设视角：企业的代码、数据、规则和流程，需要能够被 Agent 理解和使用。真正落地时，还要继续追问：能否在授权范围内执行？结果能否验证？错误能否追溯？

把“理解、约束、验证”沉淀为工程资产

每次与 AI 协作，都可以为下一次执行留下三类资产。

理解资产回答项目为什么存在、模块如何协作、关键依赖在哪里。除了文字说明，还可以包括架构图、接口契约、代码依赖和数据口径。

约束资产回答有哪些规则需要遵守。团队可以用 AGENTS.md 提供入口和关键规范，用 Skill 沉淀特定任务的流程与资源，并明确团队、项目和任务规则发生冲突时如何处理。

验证资产回答如何判断结果正确，包括可运行的测试、验收样例、检查脚本、评审要求和运行反馈。

在相关工程实践中，有一种可参考的四文件组织方式：

这是一种可参考的实现。已有文档体系的团队，可以保留原来的结构，重点建立清晰入口、可靠内容与更新机制，无需为了文件名再复制一套知识库。

企业数据还需要语义与权限

让 Agent 看见数据库表结构，并不意味着它理解业务。

例如，“本月收入”可能涉及退款、结算时间、币种和组织范围。SQL 能执行，也可能给出错误答案。

可以按任务确定查询路径：核心报表优先采用经过业务确认的查询模板；临时分析采用受语义目录、关联规则和访问策略约束的查询生成；开放探索则明确结果尚未验证。

模板也需要检查选择是否正确、参数是否合理，以及数据结构和口径是否发生变化。访问权限应由工具或数据服务实际执行，不能仅依赖提示词要求 Agent 自觉遵守。

数据助手实践：先补业务知识，再扩大分析范围

以一个处于试用阶段的数据助手案例为例，它面向业务分析场景，需要持续补充领域知识，并逐步支持原始数据层的分析。

在补充领域知识后，助手能够支持已知指标的查询和分析；更开放的下钻分析则需要继续验证。团队也将数据库查询能力封装为 Skill，供分析人员复用。

这个过程让我更明确地看到：数据助手的建设不止是接上数据库，还包括把指标定义、业务背景和分析边界整理成可复用的知识。已知指标查询跑通，只代表一部分能力成立，不能据此宣称开放分析已经成熟。

对数据助手而言，准确性、分析深度和等待时间需要一起评估。分析结果更详细，并不自动意味着工作体验更好；还要观察用户是否能在合理时间内拿到可用答案。

知识要更新，也要允许退出

部分实践用 Domain-Driven Documentation 描述这类建设，简称 DDD，即领域驱动文档。本文沿用这一命名，与通常所说的领域驱动设计区分。

其中值得借鉴的是知识的生命周期：从执行中发现经验，验证后沉淀，在使用中获得反馈，失效后退出活跃上下文。

材料中的“90 天休眠、180 天归档”是一种具体策略。实际采用时，引用频率应与规则重要性、适用版本和业务变化一起判断。灾备流程、权限边界等低频知识，不能仅因长期未被引用就失效。

自动化适合发现候选知识和过期迹象；影响范围大的规则，仍应经过负责人确认。归档也应保留来源与恢复路径。

七. 把执行、验证和异常处理接成闭环

当意图、上下文和验证方式逐渐稳定，就可以扩大 Agent 的执行范围。

一个可参考的自主流水线：评估需求、分析方案、制定计划、编码前检查、构建、审查、测试、对抗性验证、交付和反思。

这套流程最值得借鉴的，是两个不同时间点的检查。

第一道门在编码前，检查是否值得做、方向是否正确。 审查者挑战方案中的假设、约束冲突和已知失败模式，尽量在实现之前发现偏差。

第二道门在编码后，检查实际产物是否满足要求。 审查者以改动和验收证据为依据，检查正确性、兼容性、安全及系统影响。

第二道门可以使用独立上下文，减少对实现者解释的依赖，但仍应允许读取必要的规格、调用方和测试。独立审查的目的，是形成独立判断。

两个 Agent 也可能有相似盲点，因此还需要自动化测试、静态检查、运行证据和必要的人工验收共同支撑结论。

自主执行必须定义什么时候停下来

一个可运行的闭环，除了成功路径，还需要明确：

• 需求或权限不清楚时，向谁升级。
• 连续验证失败时，最多重试多少轮。
• 时间或费用达到上限时，如何停止并交接。
• 涉及高影响变更时，在哪个节点由人决定。
• 执行失败后，如何保留现场、恢复状态或回滚。

任务类型也会影响流程。“完成一个导出功能”主要按产物和验收标准判断；“把接口延迟降低到目标范围”则需要反复测量，直到外部指标达标或触发停止条件。

PR 待审、允许合并和允许生产发布，应分别设置完成条件与授权边界。

埋点校验实践：上线以后，继续和人工结果对照

在一个自动化校验案例中，Agent 被用于检查埋点是否符合要求。投入实际使用后，团队继续将 Agent 结果与人工结果对照，在版本变化中发现问题并优化。

这类任务除了检查规则，还需要关注任务引导、执行时长、失败恢复和结果留存，才能适应持续变化的测试场景。

这类实践的价值在于把验证落到了真实工作中。Agent 能运行一次，不代表能稳定覆盖不同版本和长任务；接下来应持续记录漏检、误报、人工复核成本和任务完成情况，再决定扩大哪些测试范围。这些是建议继续追踪的指标，并非已经测得的收益。

用一个需求贯穿整个流程

仍以“客户分析导出”为例，下面是一个示意流程，并非已验证的项目案例：

1. 产品明确导出对象、字段和验收场景，工程师确认权限、数据量与接口约束。
2. Agent 读取 Spec、数据目录和现有实现，提出改动计划。
3. 编码前审查发现“是否允许跨部门导出”尚未确定，任务暂停，由业务负责人确认。
4. 边界明确后，Agent 建立权限、空数据、边界日期等测试，再完成实现。
5. 编码后审查结合调用链和运行结果检查改动，通过后输出 PR、测试证据和剩余风险。
6. 经确认的新经验写回项目知识，并补充可持续运行的验证。

这个过程的价值，在于问题更早暴露，执行更少反复，同类任务下次有可靠依据可用。

八. 从一条流水线，走向团队共享的能力

当多个任务开始复用同一套知识、工具和验证流程，企业会需要更统一的能力管理方式。

可以把它理解为三类能力的协作：

• 运行与控制能力：执行环境、工具接入、任务调度、权限、预算和审计。
• 领域知识能力：业务规则、项目约束、代码与数据上下文，以及经过验证的经验。
• 交付能力：面向研发、分析、内容或其他业务的工作流与产物。

这些能力未必需要从头开发。企业更应明确哪些可以使用现有平台，哪些是需要自己长期维护的领域资产。

在组织分工上，可以借鉴 Builder、Hub、Runner 的思路：建设团队沉淀共享知识与工具；共享平台管理版本、权限和分发；面向用户的 Agent 或应用组合这些能力，完成具体任务。

团队积累的效果，应能体现为新人更快上手、重复错误减少、同类任务交付更稳定。仅仅增加文档或 Skill 数量，无法证明能力已经提升。

Agent 在群里，但工作不能只留在聊天里

在业务落地上，我倾向于优先尝试现有办公 IM。员工已经在群里讨论问题、分配任务和确认结果，让 Agent 进入已有协作环境，可以降低使用门槛。

后台系统提供受控的 MCP 或 CLI 能力，业务流程沉淀为 Skill，员工在群里发起任务和处理异常。这是一条值得试验的路径。

在群聊接入实践中，可以先验证单人 @Agent 发起任务的链路，再逐步扩展多人协作。“机器人能在群里响应”与“能够理解群内分工并持续推进任务”，需要分开建设和验收。

客服类 Agent 则适合先在有限场景中灰度验证，根据回答质量、转人工情况和用户反馈逐步扩大范围。不同 Agent 应根据业务风险和验证结果分别确定推进节奏。

但聊天入口还需要连接可追踪的任务状态、产物、责任人和执行记录。复杂数据分析、设计评审或高密度操作，也可能更适合专门界面。入口可以不同，背后的知识、权限和交付机制应尽量复用。

九. Vibe Coding 实践：用脚手架固化从理解到验收的链路

前面讨论了意图、上下文、执行验证与团队复用。回到 AI-Native 产研这条落地线，项目脚手架可以把这些能力串成日常交付流程。

在一份 Vibe Coding 工程化实践中，建设重点贯穿开发、交付和测试：让 Agent 理解项目，用 Spec 对齐需求，再把测试、独立评审和人工验收接起来。配套脚手架提供了一个具体载体，可用于新项目初始化，也可用于已有项目改造。

第一步，先建立项目事实。 新项目先确认最小必要信息；已有项目先盘点代码、配置与测试，整理架构、模块依赖和外部依赖。存在接口或持久化数据时，再补接口清单、数据模型与关系图。Agent 后续从这些材料进入项目，也能沿索引回到代码核实，减少每次从聊天重新解释项目的成本。改造已有仓库时先检查冲突，再合并规范，保留原有文档和用户修改。

第二步，把规则和任务流程分开维护。 AGENTS.md 提供入口，Rules 区分通用底线、团队规范和项目约束，Skill 承载测试、接口对齐、评审等可复用流程，并按任务适用性加载。一次需求中的临时要求不必全部上升为团队规则；反复出现且经确认的问题，才值得沉淀为共享约束。

第三步，让 Spec 成为需求与验收的共同依据。 脚手架采用开源项目 OpenSpec 管理提案、设计、规格场景和任务；以一个 Change 表达一项可独立交付、验收的需求。实现与测试围绕同一份任务台账推进，避免规划工具和执行工具各维护一套状态。边界明确、低风险且不改变产品行为的小修可以简化流程；需求、接口或验收边界变化时，则先更新规格。

第四步，让评审结论对应实际交付版本。 实现者先自查并运行适用测试，再由未参与实现的 Coding Agent 独立评审。脚手架要求留下审查范围、上下文与文件指纹；代码或相关上下文发生实质变化，旧结论就不能直接沿用。选择本地运行态联调时，还要启动真实目标、执行关键场景并记录证据；环境不可用要明确报告阻塞，不能写成通过。人工审查应优先关注高影响变更和测试本身，并保留合并决策。

第五步，把“研发交付”和“产品验收”分开。 交付文档需要把需求场景、任务、实现位置和验证证据逐项对应，并写清版本、风险、回滚方式和下一位负责人的动作。研发完成只代表进入待验收状态。产品验收后，再复盘哪些问题属于项目知识、团队规则或可复用流程，经人工确认后安排沉淀。

例如，一项导出需求的交付记录，可以把“无权限用户无法导出”对应到具体任务、权限校验实现和可重复运行的测试。验收者据此检查行为；如果验收发现字段口径遗漏，就回到规格与测试一起修正。这是上述机制的示意用法，不是额外宣称一个已验证案例。

基于钉钉群的需求流转：让下一位负责人接得住

上述链路还需要解决一个日常问题：规格准备好了，谁开始开发？研发交付了，谁来验收？脚手架为此提供钉钉项目群集成，将 OpenSpec Change 的状态变化与群内负责人提醒连接起来。

规格与交付证据保存在 Git 中，钉钉群负责把交接信息送到下一位负责人。 配置完成后，提交后的通知脚本检查需求工件和任务状态变化，按需求涉及的模块找到产品或研发负责人，在群里定向 @。它所支持的交接过程如下：

以导出需求为例，产品与工程确认范围后提交规格，群里提醒研发接手；研发完成实现、测试和评审，提交交付材料，群里再提醒产品按清单验收。验收发现偏差时，应回到需求记录中修正规格、实现或证据；完成验收、复盘与归档后，再向研发反馈结果。群里的讨论因此能够落回同一项需求，而不是散落成几段无法追踪的聊天。

这套机制围绕交接节点通知，普通任务进度变化不会逐条刷屏。交付证据缺失或仍有影响交付的待决事项时，不发送待验收通知。通知是否送达与需求是否交付是两件事：通知配置缺失或发送失败，不能据此改写仓库中的交付事实，也不能把“已经 @ 了负责人”当作对方已经验收。

这也补上了团队复用中的协作环节：不仅把流程交给 Agent 执行，还把结果、责任和下一步交到具体的人手上。 这里描述的是脚手架提供的流转机制，其运行效果仍需在实际项目中观察。

这套实践最值得借鉴的是：每次交付都留下可核对的证据，每次验收都为下一次协作提供改进依据。 文档和脚手架能够说明机制如何设计，实际能否缩短交付周期、减少返工，还需要在日常需求中持续衡量。云端编码控制平面、隔离执行和测试 Agent 的扩展，可作为后续方向，不能仅凭建设计划就视为成熟能力。

十. 先跑通一个试点，再扩大自主范围

企业无需等整套体系齐备，才开始验证价值。

可以先选择一个依赖相对清楚、验收能够执行的仓库，以及一类边界明确的任务，用一个月左右的试点观察变化。这个周期用于学习与比较，不是收益承诺。

试点按四件事推进：

1. 记录现状：确定任务范围、责任人和交付质量基线。
2. 补齐基础：建立 Spec、上下文入口、测试与关键权限边界。
3. 连接闭环：引入编码前后检查，明确人工升级和停止条件。
4. 评估与复用：比较同类任务的周期、质量和总成本，把有效经验复制到下一类任务。

如果审核和返工成本持续上升，就先缩小任务范围，找出规格、上下文或验证中的缺口。只有收益和质量得到验证，再逐步扩大自主执行权限。

我认为，AI-Native 最值得追求的变化，是把个人与 AI 协作时形成的判断、约束和经验，转化成团队可使用、可检查、可更新的能力。

代码生成只是其中一个环节。企业最终需要回答的是：下一次遇到类似需求，我们能否更少依赖临时解释，更早发现错误，并以更低的总成本交付可信的结果？

说明：本文结合行业分享与团队实践整理。案例已匿名化，省略企业与产品名称、内部工具组合、具体排期及部署状态，保留工程方法与实践边界；建议和示意流程不作为已验证成果。

2026-09-02 12:30:00

引言：从“局部提效”到“系统级重构”

随着 Cursor、GitHub Copilot、Codex 等 AI 编码工具在研发团队中的全面渗透，许多团队发现了一个残酷的现实：41% 的代码已经由 AI 生成，但顶尖团队与普通团队的效能差距却被拉大了 100%～150%。单纯提升编码速度，并没有让项目交付同步变快。

原因很简单：编码仅占软件全生命周期的 30% 左右。当 AI 把写代码的时间压缩了 80%，上游需求不清晰带来的返工更快了，未经验证的设计决策堆积更快了，下游测试与发布的瓶颈被放大得更加明显。

如果仅仅把大模型当作“高级 Copilot”或“高效打字机”，企业的 AI 化就会止步于个人单点提效，甚至陷入“局部正确、全局混乱”的陷阱。

生产力演进的三重境界

企业在推进 AI 落地时，生产力的提升通常呈现出三个递进阶段：

• 第一阶段（+30% 生产力）：AI-Assistant / Copilot 模式。人仍然在主驾驶位置，AI 坐在旁边提供协助，主要解决单点编码与补全问题。

• 第二阶段（5～10 倍能力放大）：一人全栈化。AI 成为全栈能力放大器，打破传统岗位边界，让单个工程师能够同时高效处理产品、需求、研发、测试与运维等跨领域任务。

• 第三阶段（Human-on-the-Loop 自动化）：构建自主运行系统。AI 和 Agent 在系统中传递信息、分析问题、推动任务和生成代码，人类不再卡在每一个执行节点，而是在关键位置进行监督、审核与判断。

真正的 AI-Native 转型，核心等式在于 AI-Native = Agent Readable。从“人用 AI 提效”走向“Human Directs, AI Delivers（人定方向，AI 交付）”，最终建立基于 Agentic OS 的系统级复利。

一、 第一阶段：基建与契约 —— Token 治理与 Spec 驱动

在转型的初始阶段，大多数团队面临的是“工具散乱、效果难衡量、成本不可控”的问题。要实现“人把控、AI 实现”的协同，首先必须打牢两块基石：Token 治理 与 Spec-Driven 交付。

1.1 Token 基座：网关、号池与质量监控

没有 Token 治理，就无法谈及规模化的 AI 落地。Token 治理不仅是成本控制手段，更是推进全员 AI 使用率与评估交付质量的指标中枢。

Token 基座的建设包含三个维度：

• Token 网关与号池管理：统一提供 API 中转、路由分发、计费管理与多账号号池（如绑定多 IP/AWS 主机），保障多 Agent 并发下的基础设施稳定性。

• 渗透率与使用率监控：监控各部门、各岗位的 Token 消耗与活跃度，精准识别阻碍 AI 普及的断点。

• 交付质量与 ROI 评估：将 Token 消耗与真实的产物（代码提交、PR、文档、测试用例）绑定，评估单位 Token 创造的实际业务价值，防止无意义的 Prompt 试错。

1.2 Spec-Driven 交付：人与 Agent 的“数字契约”

在传统研发流程中，需求往往通过口头沟通或模糊的文档传递。当执行主体由人类工程师转变为 AI 时，这种模糊性会导致严重的方向漂移。

工程师角色的根本转变： 过去的工程师是“写代码的人”；AI 时代/Spec 时代的工程师是“定义意图的人 + 验证质量的人”。AI 负责上下文管理、过程追溯和模板执行，人负责数据建模决策、指标口径判定和复杂业务翻译。

Spec（规格说明书）是人与 AI 协作的“数字合同”，也是全链路的唯一锚点：

• SDD（Spec-Driven Development）：通过 OpenSpec 锁定意图。上游所有决策（产品、设计、架构）都服务于写好 Spec。

• TDD（Test-Driven Development）：在下游作为验收机制。先根据 Spec 生成测试用例（Red），再生成代码实现（Green），最后进行二进制验证（Verify）。

二、 第二阶段：上下文与认知 —— Agent Readable 与三层工程资产

有了 Spec 之后，虽然消除了意图漂移，但 Agent 在执行时常常遇到“导航盲区”：不了解代码库历史、不懂业务逻辑、看不懂数据库字段含义。第二阶段的核心任务是打造 Agent Readable 的基础设施，并沉淀可持续积累的三层工程资产。

2.1 理解、约束、验证：打造可持续积累的工程资产

稳定使用 AI 的工程师，每次与 AI 协作都在同时为三层工程资产添砖加瓦；而混乱使用 AI 的工程师，每次都是从零开始，一次性用完就扔：

• 理解层（Understand）：通过架构图锚定系统级共识、通过模块图暴露代码级依赖、通过依赖图展示生态级牵挂，让 Agent 快速看懂系统全貌。

• 约束层（Constrain）：

  • AGENTS.md：定标准，告诉 AI 这是什么项目、遵守什么规范，是静态知识。

  • Skill：定流程，告诉 AI 怎么做特定的事情，是动态能力。

• 验证层（Verify）：建立质量保障体系，识别核心链路、划定测试边界、制定 Review 策略，并接入 CI/CD 与 AI 可观测性工具（如 LangSmith、Langfuse）。

2.2 让代码与数据对 Agent 可读（Agent Readable）

要让 Agent 自主做出正确判断，必须将代码和企业数据改造为“AI 易读”的结构：

1) Code 的 Agent Readable：AI-Ready Repo

代码仓库必须显式提供上下文，让 AI 理解“项目为什么存在、怎么运行、踩过什么坑、当前处于什么状态”。建议在仓库中标准化以下四类文件：

• PRODUCT.md：记录产品目标、业务优先级与成功标准。

• TECH.md：记录技术架构、硬性约束（Blocking Constraints）与关键路径。

• IMPROVEMENT.md：记录历史教训、避坑指南与踩坑反馈。

• PROJECT.md：记录当前迭代状态、关键决策与阻塞项。

2) Data 的 Agent Readable：Agent for Data

直接将自然语言交给大模型生成 SQL（裸 NL2SQL）的准确率通常仅为 60%-70%，在生产环境中几乎不可用。其根本原因在于缺少“数据含义与访问权限”的语义合约。必须建立三层数据准确度模型：

• Level 1: Certified Patterns（100% 准确）：预置经过验证的 SQL 模板，Agent 仅做参数替换与模板选择。适用于核心报表、合规推送。

• Level 2: Guided NL2SQL（~95% 准确）：NL2SQL + Catalog 语义约束（白名单 + 强制过滤 + JOIN 映射规则）。适用于临时分析与自助探索。

• Level 3: Unconstrained NL2SQL（60%-70% 准确）：无约束自由生成，仅建议作为探索参考。

2.3 DDD 知识治理：让领域知识“自己活着”

这里的 DDD 指的是 Domain-Driven Documentation（领域驱动文档），而非传统的 Domain-Driven Design。

传统知识库的最大问题是“维护税大于查询价值”——知识不断堆积，最终沦为垃圾场。AI 时代的知识治理，核心竞争力不是“记住”，而是“遗忘”：

• 达尔文衰减模式：知识被引用则强化（ref_count + 1）；90 天无引用进入休眠（Dormant）；180 天无引用自动归档死亡（Archived）。由衰减引擎每日自动执行，保持知识库的高精炼度（常态维持 80-100 条核心活规则）。

• 三条治理原则：

  • 自动生成：引擎从代码、数据与执行日志中自动提取，人类仅做审核补充。

  • 自动衰减：依靠系统机制剔除过时知识，无需定期人工 Review。

  • 自动复利：使用越多，知识网图越丰富，推荐越精准，形成知识飞轮。

三、 第三阶段：流程闭环 —— Autonomous Pipeline 与 6 个效能杠杆

当代码与数据实现 Agent Readable、且领域知识具备自我演进能力后，研发流程便可迈入全自动化阶段：Autonomous Pipeline（自主流水线）。

3.1 10 阶段闭环流水线

Autonomous Pipeline 将编码视为黑盒（Coding as Black Box），实现“一句话需求 → PR-Ready”的闭环。其典型执行链路包含 10 个阶段：

1

EVALUATE → THINK → PLAN → PRE-CHECK → BUILD → REVIEW → TEST → ADVERSARIAL → DELIVER → REFLECT

3.2 双门架构（Double-Gate Architecture）

为确保全自动流水线不输出垃圾代码，系统引入了两个独立的 Sub-Agent 质量门：

• Gate 1：做正确的事（编码前）

  • 由“怀疑者”角色（独立上下文 Sub-Agent）在 BUILD 之前挑战方案。
  • 检查方向对齐、约束违规及已知失败模式（IMPROVEMENT.md），在代码未写前拦截方向错误。

• Gate 2：正确地做事（编码后）

  • 由“攻击者”角色（独立上下文 Sub-Agent）直接攻击 ChangeSet（只看 git diff，忽略 Builder 的主观意图）。
  • 针对正确性、安全性、集成度进行 30+ 项 Review Pattern 检查，发现隐蔽 Bug。

3.3 拉开研发效能差距的 6 个杠杆

在自动化流水线之上，团队还需要通过以下 6 个工程杠杆防范返工：

• 智能自动化：将重复、易错、无聊的工作（如打包、日志排查、重复测试）交给流水线，守护高价值思考时间。

• 设计优先原则：编码前强制设计环节，AI 辅助头脑风暴，但不代替人类决策。

• 维护心流状态：保护深度工作时间，减少被打断频次。

• 降低认知负荷：减少频繁的上下文切换，精简非必要会议。

• 持续学习成长：实行教学式代码评审与配对编程。

• 优化工具链：选择现代化工具，减少技术债务，让工具“隐身”。

四、 第四阶段：协同与终局 —— 业务 AI Native 与 Agentic OS

有了强大的 Harness、Runtime 与 Pipeline 之后，Agent 应该在哪里与人类协同？

4.1 不要造新的工作台，办公 IM 才是 Agent 自然协同终局

很多企业在推动 AI 落地时，第一反应是去开发一个新的 Web Portal 或独立 App。然而，员工并不需要第 101 个独立系统。

钉钉、飞书、企业微信等办公 IM 群聊，是企业内员工信息交换最频繁、最自然的场所：

• 系统能力 MCP/CLI 化：后台业务系统的能力全部暴露为 MCP 服务或 CLI 工具。

• 业务沉淀 Skill：将业务 SOP 和岗位经验沉淀为可被 Agent 调用的 Skill。

• Agent 在群里：Agent 作为机器人直接拉入业务或研发群聊，人类直接 @它分发任务，推理过程与结果在群内透明展示。

4.2 Agentic OS 的三层解耦架构

AI-Native 转型的终局，是构建一套以系统形态自主运行的 Agentic OS：

• 底盘（Harness / Runtime）：提供执行能力（Capability），包括运行环境、Tool/MCP 接入、调度器、Hook 与渠道适配器。底盘决定 Agent“能做什么”，但不决定“该做什么”。

• 大脑（DDD Knowledge Layer）：提供判断力（Judgment），包含 4-Docs 领域知识、代码图谱、数据 Catalog 与演化反馈。

• 手脚（AgentHub / Delivery Engines）：提供交付形态，面向不同业务场景导出 Agent 服务（如 CLI、IM 机器人、Web 交互终端）。

4.3 角色重塑与系统级复利

在 Agentic OS 架构下，团队成员的分工实现了彻底重塑：

• AI 职能人员：专注于编写 Skill、MCP 接口以及沉淀领域知识，为系统补充“大脑”与“手脚”。

• AgentHub：调度各种专有 Skill 与 Agent，基于 Runtime 机制为企业内外提供全自动化的 Agent 服务。

系统每运行一次，REFLECT 机制都会将错误教训与新经验写回知识层，使下一次执行更精准，真正实现“越用越聪明”的系统级复利。

总结：避开“跳层”的陷阱

在推进 AI-Native 转型的过程中，切忌盲目跨越阶段：

• 直接跨到 Autonomous Pipeline 而缺失 DDD：Agent 虽有强执行力，但处于“盲干”状态。

• 有 DDD 但缺乏 Spec 纪律：知识丰富，但缺乏约束，导致“意图漂移”。

• 有自主执行但缺乏反馈飞轮：第 300 天的交付质量依然和第 1 天一样。

从 Token 治理 到 Spec-Driven，再到 Agent Readable、Autonomous Pipeline，最终抵达 Agentic OS，这是一条清晰而严谨的工程演进之路。只有一步一个脚印搭建好知识与控制面，才能真正释放 AI 在企业级生产中的终极价值。

2026-08-21 00:10:00

最近深度读了两个很有代表性的 Agent 项目：

• DeepSeek Harness
• AgentScope Java

它们都在解决同一个问题：怎样把“大模型 + 工具调用”变成一个能够长期运行、可以恢复、可扩展、可治理的 Agent 系统。

但读完代码后，我发现它们其实不在同一条赛道上。

DeepSeek Harness 更像一套为 Coding Agent 产品准备的可组合运行时内核；AgentScope Java 更像一套面向 Java 企业应用的Agent 框架、Harness 与服务平台。

如果只看 README，容易得出“两个项目功能差不多，只是一个用 TypeScript、一个用 Java”的结论。真正进入源码后，会看到两套完全不同的架构取向：

• DeepSeek Harness 把重点放在运行时语义：插件生命周期、事件溯源、精确回放、工具执行流水线、能力替换
• AgentScope Java 把重点放在生产运行：多租户状态、分布式恢复、长期记忆、沙箱、渠道接入和统一控制面

先说我的结论：

如果你想造一个 Coding Agent 产品，或者深度定制 Agent Runtime，DeepSeek Harness 更值得研究；如果你想把 Agent 纳入现有 Java 企业系统，并进一步做成可运营的服务，AgentScope Java 路线更直接。

一、先别急着比功能：它们不是同一层级的产品

在讨论这两个项目之前，先要回答一个基础问题：什么是 Harness？

一个最简单的 Agent 循环通常只有几步：

1. 把历史消息和工具描述发给模型
2. 模型决定回复，或者调用工具
3. 执行工具，把结果放回上下文
4. 继续循环，直到输出最终答案

这只是 ReAct Loop。真正进入生产后，系统还要处理很多模型并不关心、但工程上无法回避的问题：

• 任务跑到一半进程崩了，怎么恢复？
• 用户中途追加指令，应该插入哪一步？
• 多个工具能否并行，写操作如何避免竞争？
• 哪些命令可以直接运行，哪些必须审批？
• 上下文太长时，如何压缩但不破坏工具调用配对？
• 子 Agent 的状态、权限和工作区如何隔离？
• 同一个 Agent 如何同时服务多个用户和会话？
• 如何观察、审计和干预一个正在运行的任务？

Harness 就是包围在模型循环之外的这一整层工程系统。

从这个定义看，两边虽然都叫 Harness，但边界不同。

DeepSeek Harness 的产品边界从底层事件、工具和文件系统能力，一直延伸到 Web UI、CLI、SDK 和插件开发体系。运行中的 dsh 本身就是一棵插件树。

AgentScope Java 则更明确地分成三层：

• agentscope-core 提供模型、消息、工具、事件和 ReActAgent
• agentscope-harness 在 Core 之上叠加工作区、记忆、压缩、技能、子 Agent、沙箱等能力
• agentscope-service 再向上提供 Agent 注册、Session 管理、团队编排、Dashboard 和分布式控制面

所以，更准确的对比不是“框架 A 对框架 B”，而是：

一套高度可组合的 Agent 产品运行时，对比一套 Java Agent 框架及其生产服务平台。

二、DeepSeek Harness：把整个 Agent Runtime 做成插件树

DeepSeek Harness 最鲜明的设计不是工具多，也不是 UI 完整，而是它真的贯彻了“一切皆插件”。

底层的 Cordis 提供共享 Context、服务注册、类型化事件和可撤销副作用。模型适配器、工具注册表、会话日志、Agent Loop，甚至持久化与沙箱策略，都是挂载在同一棵树上的插件。

这意味着系统里没有一个必须不断打补丁的“神圣内核”。一个插件注册服务、工具或监听器时，这些注册都会绑定到插件生命周期；插件卸载时，副作用也会被撤销。依赖服务消失，消费它的插件会一起卸载；服务恢复后，再重新加载。

这套设计带来三个很强的能力。

1）运行时能力可以真正替换

传统框架常见的“可插拔”，其实只是允许你传一个接口实现。DeepSeek Harness 的粒度更细：

• 模型是 provider
• 文件系统是 provider
• Shell、PTY、LSP 是 provider
• Session Persistence 是 provider
• Subagent 也是 provider
• 工具、提示词片段、审批和遥测都通过事件与服务组合

例如把本地文件系统和进程执行替换成 E2B provider，Shell、文件工具等消费者可以继续复用同一套上层语义。它强调的是“能力接缝”（capability seam），而不是在每个工具内部判断当前跑在本机、容器还是远端。

这很适合构建 Coding Agent：底层执行世界会变化，但上层 Agent Loop 不应该跟着分叉。

2）插件卸载和 HMR 是架构能力，不是开发便利

因为注册本身就是可撤销副作用，DeepSeek Harness 可以在运行时卸载、替换、重新挂载插件。配置文件变化时，Loader 会比较配置项，只重载发生变化的部分；无效的新配置不会摧毁当前可用的插件树。

这不只是“保存文件后少重启一次”。它说明这个系统从一开始就在处理一个困难问题：动态变化的能力集合，如何不留下失效引用和脏状态。

对于需要安装第三方插件、切换 Agent Profile、运行不同产品形态的系统，这个底座很有价值。

3）扩展行为主要通过事件进入，而不是修改主循环

DeepSeek Harness 把事件分成三个域：

• Session Event：需要持久化、重启后仍然存在的事实
• agent/* Event：正在运行的 Agent 状态与控制
• Capability Event：文件系统、工具、遥测等能力自己的策略扩展点

例如工具执行不是简单调用一个函数，而是经过：

pre-execute → 单调守卫 → execute → post-execute → finalize → result

审批、沙箱、超时、重试、指标、结果改写都可以挂在流水线上，不必让具体工具直接依赖这些策略。

这类设计的好处是扩展面非常清楚；代价则是概念多、学习曲线陡。你必须理解 Context、Service、Effect、Scope、Waterfall Event、Profile、Bundle 和 Patch，才能真正驾驭它。

三、DeepSeek Harness 最值得看的设计：事件日志才是真相

我认为 DeepSeek Harness 最有含金量的部分，不是插件，而是它对 Session 的定义。

它把会话建模为一份只追加的事件日志。turn/start、step/start、用户消息、模型流式 chunk、完整 assistant message、工具调用、工具结果和结束边界都会进入日志。

模型看到的上下文不是另一份独立状态，而是通过 deriveMessages() 从日志投影出来。

它甚至把原则写得非常直接：

模型可见即已记录。

这句话很重要。很多 Agent 系统同时维护三份相似但不完全一致的状态：

• 发给模型的上下文
• 展示给用户的聊天记录
• 用于恢复任务的持久化快照

一旦三者漂移，就会出现最难查的 Agent Bug：界面上看到了某条消息，但模型没看到；模型根据某段隐藏上下文做了决定，但重启恢复后这段上下文丢了。

DeepSeek Harness 试图从结构上消灭这种分叉。原始流式 chunk 保证 UI 可以精确回放；完整消息用于派生模型历史；压缩通过 surface replacement 表达；fork、resume、transcript 和 telemetry 都从同一事件流产生。

Crash Recovery 也遵循这个思路：如果载入时发现一个 turn/start 没有对应的 turn/end，系统不会粗暴截断已经持久化的长任务，而是补上一个 interrupted 结束事件，保留中断前已经发生的事实。

这种做法更像事件溯源系统，而不是传统聊天记录。

它的收益是：

• 可重放
• 可审计
• 可恢复
• 可 fork
• UI 与模型上下文更容易保持一致

但它也把兼容性压力集中到了事件协议上。当前 Session 格式版本仍是 0，官方明确表示没有兼容承诺；一旦事件含义变化，迁移就会成为非常严肃的问题。

四、工具执行：DeepSeek Harness 更像调度器，AgentScope 更像企业框架

工具调用是比较两个项目时最能体现设计差异的地方。

DeepSeek Harness：每次调用动态分类

DeepSeek Harness 会为每一个待执行调用查询 executionMode：

• parallel 可以与相邻安全调用重叠
• exclusive 必须独占执行，并形成顺序屏障

Agent Loop 使用滚动并发池执行安全调用，同时保证结果仍按模型调用顺序写回。更关键的是，分类发生在调用级，而不只是工具级。理论上，同一个工具可以根据本次参数判断它是只读操作，还是需要独占的写操作。

它的工具流水线还把权限、单调守卫、沙箱、超时、重试、结果规范化和持久化观察分开。任何一层失败，都要被转成唯一、可记录的最终结果。

AgentScope Java：默认并发，加安全标记

AgentScope Java 2.0 的 Toolkit 默认开启并行执行。工具可以通过 concurrencySafe 标记自己是否能安全并发；连续的安全工具会并发运行，不安全工具形成串行槽位，输出顺序仍然保留。

这已经比“整个批次要么全并行、要么全串行”细很多，也很符合 Java 工程团队的使用习惯。但它当前主要还是工具定义级标记，表达力不如 DeepSeek Harness 的调用级动态分类。

因此，如果你在做文件编辑、终端、数据库变更这类副作用复杂的 Coding Agent，DeepSeek Harness 的执行语义更精细；如果大多数工具本身就是业务 API，AgentScope 的模型更直接，也更容易让普通团队理解。

五、Code Mode：不是让 Agent 写业务代码，而是让它编排工具

DeepSeek Harness 还有一个很有辨识度的能力：Code Mode。

普通 Function Calling 会把每个工具的完整 JSON Schema 暴露给模型，模型每调用一次工具，结果又会进入对话上下文。工具一多，Schema 和中间结果会持续占用 Token。

Code Mode 则只向模型暴露一个 run_code 入口和一份自动生成的 TypeScript 或 Python SDK。模型在临时程序中调用：

1
2
3
4
5

const files = await tools.glob({ pattern: "**/*.java" })
const results = await Promise.all(
  files.slice(0, 10).map(file => tools.read({ path: file }))
)
return results.map(item => extractWhatMatters(item))

中间工具结果留在本次执行局部，只有 return 或 console.log 的内容回到模型上下文。

这带来的价值不是“模型会写代码”——Coding Agent 本来就会——而是：

• 用程序表达循环、分支和聚合
• 独立只读调用可以显式并发
• 大量中间结果不必全部进入对话
• 工具返回值保留结构化类型，而不是来回解析文本

它本质上是把一部分 Agent 编排从自然语言推理迁移到一次性的确定性程序中。

不过 Code Mode 也不是免费午餐。当前每次运行都是全新状态，不是持久 REPL；中间值不能从会话日志重建，而且执行局部没有统一字节上限。如果程序拿回超大对象，仍然可能造成 worker 内存压力。

六、AgentScope Java：Core、Harness、Service 三层一起解决生产问题

如果说 DeepSeek Harness 的关键词是“可组合”，AgentScope Java 的关键词就是“可运营”。

它的双层 Agent 结构很清楚。

ReActAgent 负责核心推理循环，把模型、Toolkit、权限、Middleware、事件和 AgentState 组合起来；HarnessAgent 是外层包装，通过固定顺序的 Middleware 和工具，增加工作区、长期记忆、上下文压缩、技能、子 Agent、沙箱和 Plan Mode。

这种设计没有追求“一切皆插件”的纯粹性，而是刻意保留一个容易使用的 Builder：

1
2
3
4
5

HarnessAgent agent = HarnessAgent.builder()
        .name("assistant")
        .model("dashscope:qwen-plus")
        .workspace(Paths.get(".agentscope/workspace"))
        .build();

对于 Java 团队，这种体验很熟悉：核心抽象稳定，基础设施通过 Builder 和 Spring Boot Starter 接入，扩展行为走 Middleware。

更重要的是，AgentScope Java 没有停在 SDK 层。仓库中的 agentscope-service 已经把 Agent 运行进一步拆成 Gateway、Control Plane、Dataplane 和 Scheduler，并提供 Dashboard、Managed Agents 与 Agent Teams。

因此它真正想解决的不是“如何写出一个聪明的 Agent”，而是：

一家公司里有很多 Agent、很多用户和很多运行副本时，怎样统一注册、恢复、观察、调度和治理。

七、状态模型：一个强调重放，一个强调恢复与隔离

两边都重视持久化，但设计中心不同。

DeepSeek Harness：从事件重建会话

DeepSeek Harness 以 append-only Session Event Log 为 Source of Truth。状态恢复、模型历史和 UI 展示尽量从事件投影得到。

这是偏运行时语义的选择：重点是“过去到底发生了什么”。

AgentScope Java：从 RuntimeContext 找到 AgentState

AgentScope Java 把状态分成几层：

• RuntimeContext：当前调用的 userId、sessionId 和临时属性，不持久化
• AgentState：对话上下文、权限、Plan Mode 和工具状态，通过 AgentStateStore 跨调用恢复
• Session JSONL：长期保留的对话流水账
• Workspace Memory：每日只追加记忆和聚合后的 MEMORY.md
• Sandbox Snapshot：容器文件、安装依赖和运行环境的快照

同一个 Agent 实例可以服务多个用户和会话。系统通过 (userId, sessionId) 定位状态；同一 Session 的调用串行化，不同 Session 可以并行。再配合 Redis、MySQL、PostgreSQL、OSS 或 COS 等后端，实例本身可以保持无状态并水平扩容。

这是偏服务架构的选择：重点是“下一次请求由任何副本接手时，怎样继续运行”。

两种模型没有绝对高下。

• 要做可回放、可 fork、过程保真的 Agent 产品，事件溯源更有吸引力
• 要融入现有用户、租户、数据库和服务治理体系，状态存储模型更容易落地

八、沙箱：同样是隔离，关注点完全不同

DeepSeek Harness 的本地 Sandbox 更贴近开发者桌面和 Coding Agent。Linux 可使用 bubblewrap / Landlock，macOS 使用 Seatbelt，Windows 有 ACL restricted-token runner。它强调同一宿主执行世界里的文件写入边界，并且在无法落实策略时 fail closed，而不是悄悄降级为无限制执行。

远端执行则不被塞进同一个进程沙箱接口，而是通过替换文件系统与进程 provider，把整个执行世界一起移动。目前仓库也已经提供 E2B 的文件系统和进程实现。

AgentScope Java 的沙箱更偏服务部署。它把 Docker、Kubernetes、Daytona、E2B 和 AgentRun 视为同类后端，并进一步考虑：

• 按 User、Session、Agent 或 Global 隔离
• 容器消失后从快照恢复
• 快照放在本机、Redis、JDBC 或对象存储
• 多副本同时操作同一沙箱时使用分布式锁
• 对话状态和可执行环境一起跨请求续跑

所以，DeepSeek Harness 更关心“这条命令在当前执行世界里是否越界”；AgentScope Java 更关心“这个租户的执行环境能否隔离、持久并被另一台机器接手”。

九、多 Agent：一个先抽象 provider，一个先建设运营体系

DeepSeek Harness 把 Subagent 做成可替换 capability seam。不同 provider 可以在同一 Context 共存：进程内 spawn、基于历史 fork，以及对接 Codex、Claude Code、ACP 或 DSH SDK 的外部执行器。

它还区分一次性子 Agent 和可继续对话的子 Agent。后者拥有持久 Session、可冷恢复的 Activation、唯一 inbox 和明确的父子授权关系。实验性的 Agent Teams 则在其上增加 roster、task board 和 mailbox。

AgentScope Java 的多 Agent 更贴近业务使用：

• agent_spawn 创建同步或后台子任务
• agent_send 向已创建的子 Agent 继续发消息
• 超时的同步任务可以自动转为后台任务
• 后台结果通过消息总线反向通知父 Agent
• Agent Teams 提供成员、任务认领、任务板和邮箱
• Service 控制面负责跨实例注册、路由与观察

简单说，DeepSeek Harness 优先解决的是“如何把不同 Subagent 实现放到同一个抽象后面”；AgentScope Java 优先解决的是“如何让一组 Agent 在企业平台里持续协作”。

十、一张表看懂核心差异

十一、两边各自最需要警惕什么

DeepSeek Harness：架构漂亮，不等于现在就适合所有生产系统

它的风险主要有三个。

第一，项目仍处于 Developer Preview，当前版本是 0.1.0-rc.8，官方明确提示后续会有破坏性变化。Session 格式也是预发布的 v0，没有内置迁移链。

第二，Cordis 的抽象能力很强，但认知成本也高。插件树、Service 注入、Scope 隔离、Effect 回收、Waterfall Event、Bundle 和 Patch 共同工作时，调试难度不低。

第三，它更像一个完整产品底座，而不是一个轻量 SDK。如果团队只是想在已有业务里增加几个 Agent 能力，引入整套运行时未必划算。

AgentScope Java：生产面完整，但核心类正在承受复杂度

AgentScope Java 的风险也很明显。

首先，ReActAgent 和 HarnessAgent 都已经是体量很大的中心类。大量能力虽然通过 Middleware、Toolkit 和 Builder 暴露，但编排与兼容逻辑仍集中在核心实现里。未来功能继续增加时，维护成本值得关注。

其次，它的“可扩展”更接近企业框架的扩展方式，而不是 DeepSeek Harness 那种运行时级可替换。你可以加 Middleware、工具和 Store，但很难像 Cordis 一样把整个 Agent Loop 当成普通插件换掉。

最后，AgentScope Service 已经覆盖控制面、托管运行时和 Teams，能力很诱人，但这也意味着更重的部署和运维成本。只有当组织真的存在多 Agent、多租户、多副本和统一治理需求时，这一层平台才有足够回报。

十二、到底怎么选

如果你的目标是下面这些，优先研究 DeepSeek Harness：

• 做自己的 Coding Agent、IDE Agent 或桌面 Agent
• 希望替换模型、文件系统、Shell、Subagent 和持久化实现
• 强调会话回放、fork、恢复和过程保真
• 需要插件市场、动态装卸或多种产品 Profile
• 想研究 Code Mode 和更精细的工具执行语义

如果你的目标是下面这些，优先考虑 AgentScope Java：

• 企业核心系统本来就在 Java / Spring Boot 生态
• 一个 Agent 需要服务大量用户和 Session
• 需要 Redis、数据库、对象存储与跨副本恢复
• 需要长期记忆、技能治理、Channel 和多租户隔离
• 希望进一步建设 Agent Dashboard、Managed Agents 或统一控制面

还有一种常见情况：团队只是验证一个小型 Agent 功能。

这种时候，两套方案都可能太重。直接使用简单的模型 SDK、少量工具和一个清楚的状态边界，往往更合适。不要因为 Harness 很先进，就默认所有 Agent 都需要 Harness。

十三、最后的判断：它们代表了 Agent 工程化的两种未来

DeepSeek Harness 展示的是一种 Runtime-first 路线：

把 Agent 的每一项能力都变成可组合、可替换、可回收的运行时部件，再用统一事件日志保证执行语义。

AgentScope Java 展示的是一种 Production-first 路线：

把 Agent 纳入成熟的应用服务体系，解决租户、状态、沙箱、存储、渠道、调度和控制面，再让企业真正运营它。

前者更像在设计 Agent 时代的“运行时内核”，后者更像在建设 Agent 时代的“应用服务器与控制平台”。

两边最终很可能会互相靠近：DeepSeek Harness 会继续补生产基础设施，AgentScope Java 也会继续细化运行时语义。但至少在当前阶段，选型边界非常清楚：

造 Agent Runtime 和产品，选 DeepSeek Harness；在企业系统里运行和治理 Agent，选 AgentScope Java。

这也说明 Agent 开发已经进入了一个新阶段。竞争不再只是“谁的模型更聪明”或“谁的 Demo 工具更多”，而是：

谁能把不确定的模型行为，装进一套可恢复、可解释、可扩展、可治理的软件系统。

本文阅读基线为 2026 年 8 月 21 日，主要参考两个仓库当时的主干源码与文档：DeepSeek Harness 141eb6f（0.1.0-rc.8）和 AgentScope Java 643905e。关键资料包括 DeepSeek Harness 架构、Agent 生命周期、工具执行流水线、AgentScope Harness 架构、AgentScope Agent 与 AgentScope Service。

2026-08-06 11:28:00

最近一直在深度思考和实践“企业如何实现 AI Native”。

在看了大量架构方案、也踩了不少落地坑之后，我越来越确信一件事：AI Native 绝不是买几个大模型账号，也不是强行造一个新系统给员工用。

如果脱离了企业的真实数据生态和员工的习惯路径，所谓的 AI Native 改造只是一场昂贵的“技术自嗨”。

今天把最近关于 AI Native 落地的前提、短中期痛点、协同载体以及终局形态的思考梳理出来，供大家参考。

一、企业级 AI Native 落地全景架构

在探讨具体协同载体之前，我们先拉高视角，看一张企业级 AI Native 落地全景架构图。

整个架构从上到下分为应用场景层、能力解耦层、核心 Runtime 运行时以及底座资源支撑层：

这张架构图体现了两个核心逻辑： 1. 能力解耦与治理（Skill/MCP Hub）：将数据、工具和系统能力标准化暴露，解决安全鉴权与复用问题。 2. 场景双轮驱动：既包含了研发侧的 Vibe Coding，也涵盖了全公司业务与职能形态的 Agent 化。

后文讨论的所有“Agent Readable”、“IM 协同”以及“私有 Runtime”，本质上都是这张架构图在具体工程和组织管理中的落地延伸。

二、AI Native 的首要前提：解决 Agent Readable

绝大多数企业在喊 AI Native 时，第一步就卡住了。

原因很简单：大模型虽然聪明，但它对企业内部的真实情况一无所知。

企业要真正走向 AI Native，第一个关键基础设施不是选哪个模型，而是实现 Agent Readable（Agent 可读化）：

• 数据可读：数据库、数据仓库、日志、指标是否暴露成了 Agent 可领会的结构？
• 文档与知识可读：PRD、合同、FAQ、研发文档是否离散在各种乱七八糟的本地文件夹里？
• 系统与资源可读：企业的各种业务后台、HR 系统、财务系统、CI/CD 管道，是否有标准的 MCP Server 或 API 供 Agent 发现与调用？

只有企业的核心数据、知识与资源变成了 Agent 可以安全获取、读取和理解的形式，AI Native 的改造才有底座。

三、冷静看效益：短期是成本，长期才是提效

很多人对 AI Native 抱有不切实际的幻想，认为一旦引入立刻就能全员提效。

现实往往相反：短期内，AI Native 改造大概率是降效的。

引入新技术必然带来额外的成本：

• 学习成本：员工需要学习如何与 Agent 交互、如何撰写规范的 Prompt 和设计约束。
• 改造成本：系统 API 的 MCP 化改造、数据治理、安全与风控护栏的搭建。
• 磨合成本：人机协同流程中的摩擦与失控风险。

管理者必须有清醒的认知：短期内我们在为“认知升级和工程基础设施”买单，长期来看，当 Agent 能够自主吞吐数据与执行流程时，指数级的提效才会真正爆发。

四、为什么办公 IM 是 AI Native 的最佳协作载体？

最近观察到飞书、钉钉、企微等办公软件频繁调整组织架构和 AI 战略，这与我们探索的“企业 Workspace”方向完全吻合。

未来企业真的需要为了 AI 专门再开发一套全新的协作平台吗？答案大概率是：不需要，甚至应该坚决避免。

重新造一个新平台，面临最大的阻力就是用户习惯路径的迁移。而钉钉/飞书/企微有着得天独厚的优势：

1. 资源天然沉淀：企业的组织架构、文档、审批、知识库早已沉淀在上面，天然具备实现 Agent Readable 的基础。
2. 零迁移阻力：员工早已习惯了每天在上面沟通和协同，不需要改变任何工作习惯。
3. 天然的 Agent 学习场（群聊即 SOP）：
   • 协作最好的形式可能就是群聊（正如海外企业在 Slack 中实现的那样）。
   • 传统企业写 SOP 是极其昂贵且容易过期的，但群聊历史天然是“带有上下文、有纠错过程、有结果验证”的真实表达。Agent 驻留在群里，只需观察群里的历史沟通，就能通过无感的 In-Context Learning 隐性学习到团队的业务 SOP 和规则，自然而然掌握这项技能。

五、终局思考：私有大脑 + 标准 IM 接口

虽然用户界面不需要自研，但这并不意味着企业不需要自己的基础设施。

从数据安全性、模型路由与 Runtime 多样性的角度来看，企业必须拥有私有的 Agent 运行与治理能力。

因此，理想的终局形态是明确的解耦：UI 交互层归办公 IM，运行治理层（私有大脑）归企业自建。

• 交互层（办公 IM）：提供人类最熟悉的 UI 和消息通道，零成本承载人机协同。
• 治理层（私有 Runtime）：承载真正的核心逻辑、私有模型路由（TokenHub）、代码沙箱隔离（Sandbox）以及自定义 MCP 工具链。

试想这样一个未来的产研闭环场景：

1. 需求提出：你在钉钉/飞书的项目协作群里，直接 @产品经理 Agent：“我们需要增加一个根据用户行为自动生成周报的功能。”
2. 需求细化：产品经理 Agent 接到需求，在群里进行需求拆解与澄清，生成结构化 PRD，随后自动 @研发 Agent。
3. 代码与部署：研发 Agent 分析需求、设计架构、编写代码，并通过 CI/CD 自动部署到测试环境，最后 @产品经理 Agent 验收。
4. 验收上线：产品经理 Agent 完成验收，自动触发发布流程，并在群里汇报“已上线”。

在这个过程中：

• 全流程透明：人类管理者和团队成员可以在群里看到所有的执行节点与进度。
• 随时介入：一旦 Agent 在任何一步偏离预期或遇到风险，人类可以随时 @ 介入打断或修正。
• 闭环打通：完全打通了从需求到上线的产研全流程。

六、总结

总结来看，企业 AI Native 改造的底层主线已经非常清晰：

1. 以 Agent Readable 为基石：搞好数据治理与能力暴露。
2. 以成熟 IM 为协同界面：借力钉钉/飞书/企微，降低用户迁移门槛，用群聊作为 Agent 学习与交互的场。
3. 以私有 Runtime 为安全大脑：保证数据安全、管控模型成本（TokenHub），并实现多 Agent 的群流转。

打破幻想，扎实建设基础设施，才能真正拥抱 AI Native 的时代。

2026-07-05 10:00:00

2026 年上半年，AI 的演进明显从“单点能力竞赛”转向“完整工作能力竞赛”：模型开始统一推理、编程、多模态和工具调用，Agent 从演示走进真实工作流，图像与视频生成也在加速进入生产链路。

概括总结一下 2026 年上半年的关键 AI 事件。

半年观察

1. 编程模型与通用模型正在合流

GPT-5.3-Codex 到 GPT-5.4 的演进很有代表性：编程、终端操作、工具调用和 Computer Use 不再只是专用模型的附加能力，而是逐渐并入通用主线模型。模型的衡量标准，也从回答一道题转向能否在真实环境中持续完成一项工作。

2. Agent 的竞争焦点转向工作流

Claude Code Dynamic Workflows、Gemini Spark，以及各家模型不断增强的浏览器和终端能力，共同说明 Agent 已经进入工程化阶段。上下文长度和单次推理成绩仍然重要，但任务拆解、工具协作、长时间运行、结果校验和失败恢复，正在成为决定实际体验的关键。

3. 多模态开始接管专业生产链路

Nano Banana 2、GPT-Image-Gen-2 和 Seedance 2.0 分别推动图片编辑、视觉表达与音视频联合生成。与此同时，Claude 通过连接 Adobe、Blender、Fusion 和 Ableton 等工具进入专业创作环境。多模态模型不再只负责“生成一个作品”，而是开始参与素材理解、编辑和交付的完整流程。

4. 模型分层更加清晰

2026 年上半年，各家都在同时经营旗舰模型、高性价比模型和受控专业模型。Pro、Sonnet、Flash、Lite、Fable、Mythos 等不同定位背后，是同一个趋势：企业不再只选“最强模型”，而是根据任务难度、延迟、成本和安全边界动态选择模型。

小结

如果说 2025 年的关键词是推理模型、多模态和 Agent 的集中爆发，那么 2026 年上半年更像是这些能力的汇合：模型正在成为一个能读懂环境、调用工具、组织任务并交付结果的工作系统。

下半年的竞争重点，也会从“谁又刷新了榜单”，进一步转向“谁能用更低成本、更稳定地完成真实任务”。

2026-05-17 11:44:00

最近大量使用 AI 进行开发，我逐渐意识到一个趋势：随着 AI 编程的普及，被颠覆的不仅仅是一线工程师的工作方式，对 CTO、技术总监、技术 Leader 这些技术管理者的要求，正在发生截然不同的改变。

过去，技术管理的核心在于“人”与“确定性”；而现在，当 AI 开始接管代码生成，系统正在变得“非确定性”。如何理解和控制这种非确定性，将成为下一代技术管理者的核心壁垒。

传统的确定性时代：管组织与做平衡

在传统的软件工程时代，代码由工程师一行行敲出来，系统严格按照设定的逻辑执行。

这种模式下，系统是高度确定性的：输入相同，输出必然相同。如果出了 Bug，顺着调用栈一层层 Debug，总能找到引发异常的那行代码。因此，技术管理者不需要每天盯着系统的细枝末节，核心精力主要放在以下三件事：

• 管理复杂组织：搭建梯队、拆分团队、把控研发效能。
• 决策技术路线：选型、架构演进、技术债务管理。
• 平衡业务与工程：在有限的资源下，平衡需求交付进度与系统长期健康度。

AI 编程时代：非确定性带来的失控感

当研发流程全面接入 AI，情况变了。

现在是工程师设计约束，AI 负责生成代码。这种模式打破了传统的确定性——同样的输入，AI 每次给出的实现细节可能完全不同。这带来了一系列连锁反应：

• 调试极其复杂：代码不再是人类思维的直接映射，遇到 Bug 时，由于存在机器生成的不可解释性，排查链路变长。
• 系统难以理解：大量 AI 生成的代码交织在一起，如果不加以严格规范，系统会变成一个连创造者都看不透的黑盒。
• 风险更难控制：非确定性的代码直接进入工程环节，边界变得模糊，安全和可用性风险急剧上升。

技术管理者的新定位

在这样的背景下，技术管理者的核心工作，正在从单纯的“管人”向“管系统行为”演进。未来的首要任务，是解决“如何完全理解系统为什么这么运行”的问题。

技术管理者的新角色正在转变为：

• 系统约束设计者：从设计架构，转变为设计“AI 生成与运行的约束条件”。通过制定严格的上下文准入边界、静态检查校验规则以及自动化测试拦截网，让 AI 在可控轨道内工作。
• AI 能力整合者：准确判断系统的哪些模块该用传统逻辑保底，哪些模块可以放权给 AI 生成。将大模型能力无缝、安全地整合进既有的工程开发链路中。
• 风险控制负责人：面对非确定性输出，必须建立一套全新的兜底与熔断机制。从架构设计上控制 AI 产生错误代码或不可控行为的爆炸半径。

结语：建立全新的认知框架

本质上，AI 时代的研发管理，需要建立一套全新的认知框架。

从管理“人类开发者的产能”，升级为管理“人机协同系统的行为边界”。对现有的技术管理者来说，这不仅是脱离舒适区的巨大挑战，更是抓住下一次技术代差、重塑团队战斗力的绝佳机会。