AI 写代码越快，企业越需要自己的 Harness

周六在上海的 AI Maker Summit 大会上，分享了一下我们在 Harness Coding 上的一些实践。

这次也把分享时使用的 PPT ，以及我演讲前准备的完整口播稿，一起放到公众号上。

这里先多聊两句。

我个人做 PPT 的习惯，一般是先把整场 PPT 梳理出来，然后再针对每一页，单独写对应的口播稿。

写口播稿并不是为了逐字背诵，更多是为了提前把整场分享过一遍。

而真正到了现场，我会基于每一页 PPT 建立几个自己的演讲锚点，只记住关键的核心内容，具体怎么讲，会根据现场状态调整。

所以这篇文章里放出来的，是我演讲前准备的版本，和当天实际讲出来的内容会有一些差异，但整体逻辑和核心观点基本一致。

另外，因为它本质上是一份口播稿，不是按照公众号文章重新写的一篇长文，所以读起来会更口语化一些，也会保留一些现场转场和重复说明。

大家可以把它理解成：

这场分享的 PPT ＋完整演讲底稿。

接下来，正式开始。

关于 Harness ，在我的体感里，大概是从 25 年 11 月份，Anthropic 对外发表关于长任务运行的工程实践开始。

整个 AI Coding 领域，开始逐步从 Vibe Coding 往更加工程化的方向演进。

然后到了 26 年 2 月份，OpenAI 又发表了一系列 Harness Engineering 相关的内容。

此时关于 Harness 、反馈回路这些话题，也逐渐在国内开始蔓延。

所以其实你现在如果想学习 Harness ，能够找到的材料已经很多了。

OpenAI 、Anthropic 的工程文章，开源项目，还有各个团队的实践，都可以拿来参考。

我们自己学习的时候，也会让 AI 帮忙读这些资料，梳理里面的思路，再放到自己的项目里尝试。

所以方法越来越容易获得，模型本身也一直在进步。

那我们还在线下分享这些东西，有什么价值？

这个我思来想去，我觉得价值其实就在大家各自不同的经历里。

同一个方法，到了不同的项目中，可能会遇到完全不同的问题。

我们做过哪些优化，后来为什么又改了，哪些东西最后留下来了，这些细节往往比单纯地再读一篇博客更值得交流。

所以我今天想分享的，也主要是这些内容。

从我们最开始遇到了什么问题，到围绕这些问题做了哪些优化，再到这些设计真正放进一次开发任务里以后，到底是怎么工作的。

对于刚接触 Harness 的朋友，我会尽量用一个简单的例子把整个过程讲清楚。

已经在实践的朋友，也可以对照一下自己的项目，看看我们的取舍是不是一样。

我们遇到类似的问题，差不多也是在 4 月份的时候。

当时我们在用 AI 编程的过程中，比较明显地遇到了两个问题。

第一个是测试。

Agent 告诉我们，代码已经改好了，测试也做完了。

但再去看实际执行情况，会发现验证并没有充分完成。

它最后给出的完成总结，和我们真正能够核对的结果之间，还是存在一些距离。

第二个是架构。

AI 改出来的功能可以用，但是没有遵守项目原来的模块约定。

我举一个比较通用的例子。

一般一个软件产品里，都会有用户账号管理相关的功能。

账号模块通常会有自己独立的封装，账号状态变更、权限校验等逻辑都会在这里处理。

但是 AI 在实现某个业务功能的时候，可能没有复用账号模块，而是直接去修改账号表。

短期来看，状态确实改成功了。

但是从整体代码来看，它已经偏离了我们最初定义的架构规范。

这两类问题都在提醒我们：

AI 交付产物的时候，我们不能只看它最后回答了什么。

代码到底是怎么实现的，经过了哪些验证，有没有破坏项目原来的架构约定，这些我们都需要有办法看清楚。

只有这样，我们才能更加信任 AI 在企业业务场景下的产出。

那这两个问题，其实都指向了同一个更根本的问题。

现在通用的 Coding Agent ，已经非常擅长改文件、执行命令这些具体工作了。

那为什么真正进入项目以后，它的产出还是经常达不到我们想要的要求？

后来我们把这个问题拆下来，发现主要来自四个方面。

这个地方我觉得很重要。

因为后面我们会讲到 OpenWiki 、知识地图、多 Agent 、Hook ，这些其实都是“术”，都是具体执行层面的手段。

那它背后的“道”，也就是我们真正需要解决的根因是什么？

就是下面这四个问题。

第一，模型本身很擅长基于当前上下文去理解和推理下一步应该做什么。

但它天然不知道你们项目里的真实事实。

比如，它不知道这段代码背后曾经出现过哪些故障，也不知道为什么当年做了某个特殊的设计，更不知道里面可能存在什么历史债务。

所以这些项目上下文的缺口，需要我们通过一系列技术手段主动提供给模型。

也就是：它知道吗？

第二：它做得到吗？

即使 Agent 推理出来它应该做什么，也不代表它真的有办法完成。

比如，它知道这个时候应该去查看上下游服务日志，但是没有访问日志平台的工具。

它也知道应该运行集成测试，但没有办法启动相关的上下游服务。

因此，除了给它项目事实以外，我们还需要给它提供真实的工具、运行环境、权限和操作入口。

这一层解决的是：

让它不只是知道应该做什么，而且真的做得到。

第三：它看得见结果吗？

Agent 做完动作以后，我们还需要把真实的运行结果交给它。

比如测试到底有没有通过，接口真实返回了什么，数据库状态有没有发生变化，当前的覆盖率和性能指标到底是多少。

这样它才能根据真实结果，判断下一步应该做什么。

这一层解决的是：

让判断建立在真实结果上，而不是模型自己的预期上。

第四：它知道什么时候才算结束吗？

即使 Agent 已经拿到了真实结果，它也不天然知道哪些条件必须全部满足以后，这个任务才允许结束。

它可能只运行了单元测试，没有运行集成测试。

也可能某个检查已经失败了，但它觉得这个问题不重要，于是仍然决定继续往下走。

所以我们需要提前定义清楚完成标准，再通过 Hook 、脚本、CI 、合并策略和人工审批，把这些标准真正接到控制点上。

比如覆盖率必须达到 80%，架构检查不能失败。

任何一个必要条件不满足，就不能结束，也不能进行代码合并。

这一层解决的是：

不只是告诉 Agent 什么叫完成，而是让不满足条件的任务无法被当成完成。

所以整个项目级 Harness 真正要解决的，可以总结成四句话：

第一：给 Agent 注入正确的项目上下文；

第二：给 Agent 在真实环境中行动的能力；

第三：把真实的运行结果反馈给 Agent ；

第四：不满足完成条件，就不允许任务结束。

所以后面我们讲到的 OpenWiki 、Spec 、测试脚本、Hook ，甚至多 Agent ，其实都是围绕这四个问题在解决。

这些都是术。

而这四个问题，才是为什么通用 Coding Agent 进入真实项目以后，我们仍然需要项目级 Harness 的根本原因。

接下来我们用一个比较简单的业务场景来举例，然后一步一步往下深入，看一套项目级 Harness 是怎么逐渐长出来的。

比如我们给 AI 的原始需求是：

开发一个新的需求，历史账号只有完成迁移以后，才能走激活流程，其他账号不受影响。

这个时候第一步，我们需要先把原始需求转成可检查的 Spec 文档。

也就是把一句自然语言需求，变成后面可以真正拿来开发和验收的依据。

什么意思呢？

当这个需求丢给模型以后，它首先需要查清楚项目事实，然后分析需求。

比如这里说：

其他正常账号不受影响。

那“正常账号”到底指什么？

可能是 ID 带某种公司标识的账号，属于系统原有账号；不带公司标识的，则属于历史迁移账号。

那针对历史迁移账号，就必须在迁移完成以后，才能进行账号激活。

这些条件需要先写进对应的 Spec 文档，再和人类进行对齐。

那这里大家可能会有一个疑问：

我们怎么保证模型先调研项目事实、对齐需求、生成 Spec ，然后才能继续下一步？

其实很简单。

第一，我们在项目的 AGENTS.md 中把工作流程写清楚。

如果用户只是查询问题、解释代码，就正常调研和回答。

如果用户要求开发或者修改功能，就先查清楚项目事实，把需求中的模糊条件、待确认问题和验收标准，按照模板写进当前需求对应的 Spec 文档。

和用户对齐以后，再开始开发。

但只写规则，AI 是有可能跳过的。

所以第二步，我们再加一个 Hook 检查。

Hook 可以简单理解为：

Agent 运行到某个指定环节时，会自动执行我们提前配置好的程序。

这里使用的是 PreToolUse ，也就是“工具执行前的钩子”。

当 AI 准备调用工具修改代码的时候，代码还没有真正被修改，检查脚本就会先执行。

脚本检查当前需求对应的 Spec 是否存在。

如果不存在，就返回一个“拒绝”的结果，并告诉 Agent：

请先编写 Spec ，再修改代码。

Codex 收到这个结果以后，就不会执行这次代码修改，同时把拒绝原因反馈给模型。

读取资料、查询代码，以及编写 Spec 本身，仍然可以正常进行。

我们当时的实现里，会把当前会话 ID 和对应的 Spec 做关联，脚本检查当前任务有没有建立对应的 Spec 。

有，则继续。

没有，则拒绝。

这样一来，AGENTS.md 负责告诉 AI 应该怎么做，Hook 负责在关键动作上检查它有没有做到。

这个时候，整个 Agent 的控制才开始逐渐成型。

当然，既然涉及到 Spec ，就一定还会涉及到 Spec 的生命周期。

什么时候归档？

哪些内容应该长期保留？

哪些内容本次任务结束以后就可以关闭？

这里可以单独写一个 Skill ，负责整理当前 Spec 。

任务结束以后进行归档，同时判断这次 Spec 里有没有值得长期沉淀的知识。

有，就输出到指定的知识目录。

没有，就正常关闭。

这里讲到 Spec ，大家可能会想到 OpenSpec 或者 SpecKit 。

我觉得大家都可以去参考它们的实现原理。

现在想搞清楚一个工具具体是怎么实现的，其实并不难。

更重要的是看懂它解决什么问题，然后基于自己的项目做适配。

比如 OpenSpec ，前期我们也用过。

后面随着模型能力增强，我们会觉得里面有些流程稍微有点重。

比如强制把大量代码变更细节也同步到文档里。

实际人类审核的时候，很多时候并不会真的去看这一层。

还有 Superpowers 。

我自己的体感是，它的 Brainstorming 很不错，但整套开发流程相对比较重，会明显拉长模型执行路径。

所以我现在反而比较推荐大家：

先理解这些工具背后的思想，再根据自己的场景，做一套适合自己的轻量版本。

输出完 Spec ，并和人类对齐完需求以后，就开始进入实现阶段。

一般情况下，在多 Agent 调度里，可以看到两种比较典型的架构模式。

一种是主 Agent 负责需求、规划和主要开发，子 Agent 负责独立评审。

也就是主 Agent 干活，其他 Agent 负责“对抗”。

还有一种是主 Agent 只负责规划和调度，本身不参与具体实现。

我们第一阶段采用的主要是第一种。

它最大的好处是简单。

主 Agent 在一个会话里拥有相对完整的上下文，交接也比较少。

后续随着任务复杂度提高，我们也逐渐转到了第二种模式，这个后面再聊。

先看第一种模式。

Spec 生成以后，说明我们已经有了这次需求共同的依据。

这个依据可以辅助主 Agent 开发，也可以辅助它生成对应的测试用例。

主 Agent 工作完成后，会调用测试评审 Agent ，对本次实现进行评审。

测试评审 Agent 会基于原始 Spec ，检查主 Agent 编写的测试用例是不是真的覆盖了需求中的所有场景。

如果有遗漏，就驳回。

没有问题，再通过。

架构评审 Agent 也是一样。

它会检查主 Agent 这次的代码变更，有没有违反项目原来的架构规范。

比如出现不合理的跨包引用，或者绕过已有模块直接访问数据。

发现问题，同样打回。

那这里又会涉及一个问题：

为什么主 Agent 会主动调用这些子 Agent 来做收尾？

这里主要有两个机制。

第一，我们会在工作流里明确约定，代码实现完成以后，需要进入对应的评审环节。

Agent 在正常执行流程的时候，大概率会主动触发。

评审 Agent 产生的结果，也会和当前 Spec 一起保存下来。

第二，如果 Agent 没有执行对应的评审，我们还可以在 Git 提交的时候做统一检查。

比如检查当前 Spec 有没有对应的测试评审和架构评审结果。

如果没有，就拒绝提交。

最终想完成提交，就需要执行我们封装好的收尾 Skill 。

这个 Skill 会检查：

当前 Spec 对应的审核状态是不是完整的？

同时也会扫描这次 Spec 里，有没有值得长期沉淀的项目知识。

什么叫长期值得沉淀的知识？

比如：

“这个需求最后是怎么写代码实现的”，通常不是特别重要。

但：

“这个项目到底通过什么规则判断一个账号是不是历史账号”，这就是长期有价值的项目事实。

这类内容就值得从一次性的 Spec 里抽出来，沉淀成项目长期知识。

到这里，我们其实已经构建出了一个基本的开发闭环。

但如果只是这样，是不是就够了？

是，也不是。

前面的开发和评审流程，能够帮助我们降低本次实现中需求遗漏、测试不足和架构偏移的概率。

但是还有一个问题：

集成测试怎么办？

比如历史账号没有迁移完成，就拒绝激活。

这个逻辑在账号服务内部验证没有问题。

但是登录链路怎么办？

账号只有在激活成功以后，才能进行登录。

我们前面一直在解决：

激活的时候，如何判断这个账号到底允不允许激活。

但如果把激活接口和登录接口连在一起做集成测试，事情就没有这么简单了。

Agent 怎么知道登录服务里还有哪些与历史账号相关的规则？

会不会存在这种逻辑：

虽然账号已经激活了，但历史账号仍然不能从当前入口登录，而是需要从另外一个入口进入？

我不知道，那 Agent 怎么知道？

这个时候，就涉及到知识地图。

什么叫知识地图？

我理解它最核心的价值，就是：

给 Agent 建立一套可以查找、可以关联、也可以追溯依据的项目事实。

一般情况下，一个项目里的知识，除了源码之外，还会有故障复盘、解决方案文档、业务知识、架构决策等等。

所以 AGENTS.md 我一般建议尽可能保持简短。

它更像一个入口和导航，不应该把所有知识都堆进去。

真正复杂的知识，通过关联的方式让 Agent 按需继续读取。

这里就会涉及到 LLM Wiki 。

不知道大家有没有听过。

大概 5 月份的时候 Karpathy 提出这个概念以后，有一段时间还挺火的。

它的核心思想其实非常直观：

像构建 Wiki 一样，为整个项目建立一张适合 LLM 阅读和导航的知识地图。

后来 Google 又在这个方向上推进了一套开放知识格式，也就是 Open Knowledge Format ，OKF。

简单理解：

OKF 更偏知识组织规范，OpenWiki 是一个具体的 Wiki 生成和维护工具。

当知识输入主要来自源码时，生成出来的内容自然会更多偏向代码事实。

比如模块之间是什么关系，接口在哪里，某个类被谁调用。

但我们也可以把业务知识、故障复盘、解决方案文档等资料放进明确的目录，再让 OpenWiki 一起纳入知识整理。

这样最终生成出来的知识地图，就不只是“代码是怎么写的”。

还会包含：

为什么这样写，当时解决了什么问题，以及这段代码背后有哪些业务背景。

当知识地图建立以后，账号激活和登录之间的关系、历史账号的特殊规则，就都有机会在这张地图上被关联起来。

当然，知识地图真正难的地方，现在已经不完全是怎么生成。

更难的是：

哪些内容有资格成为事实？

比如哪些架构文档仍然有效，哪些故障复盘代表当前项目，哪些历史解决方案已经过期。

只要涉及知识，就一定会涉及知识生命周期。

知识什么时候产生？

什么时候失效？

怎么判断可信度？

Agent 在消费一条知识之前，能不能知道它来自哪里、什么时候更新、有没有被验证？

我觉得这反而是后面非常重要的一件事情。

OKF 这类标准很大的价值，也是在推动这类知识生命周期的问题逐渐标准化。

我们最开始其实也是基于 LLM Wiki 的思路在做自己的知识地图。

后面有了 OKF 以后，我们就直接开始往这个标准上靠。

知识地图的核心，不是再给 Agent 多生成一些文档，而是给它建立一套可以相信、可以追溯的事实依据。

这里大家可能也会想到 RAG 、知识图谱、本体论这些概念。

从我自己的实践感知来看，对于大多数软件项目，LLM Wiki 这种形式会更加轻量。

知识图谱、本体论当然也有它们的价值，但整体会重很多。

这个每个团队的场景不同，大家可以根据自己的需要继续验证。

那知识地图构建完以后，有了更加完整的项目事实依据，集成测试这件事情就开始变得不一样了。

集成测试 Agent 可以结合当前 Spec 和项目知识，判断这次变更可能影响哪些上下游链路。

比如账号激活以后，登录链路就应该一起验证。

这个时候可以准备三类账号数据：

历史已迁移账号；

历史未迁移账号；

原生账号。

然后验证激活流程和登录流程。

必要的时候再进一步检查数据库状态，甚至调用后续查询车辆等业务接口，验证整条链路是不是正常。

这个时候，我们验证的就不再只是“激活接口写对了吗”，而是“用户最终能不能走完整个业务流程”。

但是这样就够了吗？

当然还不够。

既然是集成测试，就一定涉及真实服务的运行。

服务运行以后，又会涉及数据库隔离，以及下游业务异常的时候怎么排查。

这个时候，我们就需要解决前面讲的第二个问题：

它做得到吗？

要让 Agent 真正拥有执行和排查问题的能力。

这时候就会涉及基础设施上的一系列改造。

比如几乎每家公司都会有自己的日志平台或者可观测平台。

集成测试的时候，我们不太可能把整个微服务体系全部启动在本地。

更多情况下，是本地或者隔离环境启动当前服务，其他依赖调用开发或者测试环境中的服务。

那如果下游接口出现异常：

Agent 怎么知道问题出在哪里？

怎么查看下游服务日志？

这个时候，日志平台或者可观测平台就需要给研发 Agent 提供可以直接使用的查询能力。

可以通过 Skill 、MCP 或者内部 API 等方式，把这类能力暴露出来。

让项目里的 Agent 在需要的时候，可以自己查询相关服务的日志。

数据库也是一样。

给 Agent 提供受控的数据库查询能力，让它能够核对数据状态、定位问题。

到这里，集成测试 Agent 才真正具备可测试、可诊断、可反馈的能力。

那此时整个需求闭环就变成了：

人类先对齐原始需求。

主 Agent 负责实现当前 Spec 。

测试评审 Agent 和架构评审 Agent 提供独立检查。

然后再进入集成测试，对真实业务链路进行验证。

集成测试除了验证上下游业务行为以外，也可以结合项目标准检查 JaCoCo 覆盖率、安全扫描等结果。

这些结果达到项目定义的门禁以后，这次任务才允许继续往下走。

到这里，一次需求从定义到实现，再到跨服务验证，基本形成了完整闭环。

但是，这就结束了吗？

还没有。

需求和测试完成，不代表整个任务已经收尾。

这个时候，我们还需要做最后一次统一检查。

例如扫描当前任务所关联的 Spec ，看它是不是留下了足够完整的交付证据：

是否存在标准格式的 Spec ；
测试评审是否已经完成；
架构评审是否已经完成；
集成测试是否已经通过；
必要的质量检查是否满足项目标准。

如果缺少必要证据，就打回，禁止进入最终提交。

如果都满足了，再进入知识整理阶段。

代码事实可以重新进入知识地图更新。

如果这次任务暴露出新的业务知识，就把它整理成长期知识。

如果发现新的架构问题，也可以反过来继续完善架构检查规则。

这个时候，一次任务才真正完成了从开发、验证到知识回流的闭环。

前面讲的这些，基本都是基于：

主 Agent 推进任务，评审 Agent 提供对抗反馈。

但是当项目知识地图和各类 Agent 能力真正建立起来以后，你会发现，想使用它的人会越来越多。

比如运维同学会问：

线上出现异常告警的时候，能不能直接让 Agent 先排查一下，到底是什么原因？

测试同学也会问：

我提 Bug 的时候，能不能先让 Agent 判断一下，这到底是车端的问题、云端的问题，还是 App 端的问题？

这样就不用每次先把 Bug 扔给一个人，再由这个人判断应该分给谁。

这个时候你会发现一个问题：

我们现在这套 Agent 能力，都只跑在开发者自己的电脑上。

它依赖本地的 Claude Code 、Codex 或者 Qoder 启动以后才能工作。

那其他人怎么使用？

换句话说：

既然 Agent 已经能够解决研发内部的问题，那它有没有可能进一步进入研发上下游的工作场景？

怎么把研发 Agent 的能力，从“开发者本地工具”变成“团队可以共同调用的能力”？

这个时候，就开始进入平台化的问题了。

大家可能会联想到飞书 CodeM 这种把 Agent 融进研发协作体系的产品方向。

但这类产品目前还在快速迭代，我们自己又确实已经出现了类似诉求。

所以后来我们基于开源的 Multica 做了一些二次开发，把项目里的 Harness 能力逐渐搬到一个团队可以共同使用的平台上。

以前我还有一个担忧。

我们在项目里构建了一套 Harness ，里面会涉及不少脚本、工具和环境配置。

那这些东西在我自己的 Mac 上跑通了，不代表在 Windows 上一定没问题。

如果每个开发者都需要在自己电脑上安装和维护整套 Harness ，机器兼容和版本升级本身也会变成新的成本。

平台化以后，这件事情反而简单了一些。

我们只需要准备固定的 Agent Runtime ，注册到 Harness 平台上。

其他人通过平台创建任务，把任务分配给对应的 Agent 。

平台负责统一管理任务状态。

Agent 在做什么、现在进行到哪一步、卡在哪里，团队都可以直接看到。

如果需要开发代码，就由研发 Agent 拉对应 Worktree ，完成代码开发，走完整套评审和测试流程，最后自己提交 PR 到 GitLab 。

这样一来，就不需要每个人都在本地维护完整的 Agent 环境。

研发、测试、运维等不同角色，都可以通过平台直接调用项目 Agent 。

我们要做的，是维护好 Agent 的能力、工具和权限。

需要升级的时候，在统一的 Runtime 上更新即可，不需要每台开发机器分别处理。

比如我们针对云平台项目，建立了一套项目小队。

里面可以有项目负责人 Agent 、研发 Agent 、测试 Agent 等不同角色。

如果只是一个明确的问题，可以直接找对应的研发或者测试 Agent 。

如果你自己也不知道这个任务应该找谁，那就直接交给项目负责人 Agent 。

由它判断任务类型，再调度其他角色完成工作。

研发 Agent 完成实现以后，由测试 Agent 验证。

项目负责人 Agent 负责把任务从需求、开发、测试一直推进到最终交付。

这就从最初：

一个主 Agent 自己做大部分事情，再调用其他 Agent 评审，

逐渐演变成：

主 Agent 只负责目标、委派、调度和结果整合。

也就是前面提到的第二种架构。

当然，多 Agent 也会带来新的问题。

比如上下文交接、任务依赖、Agent 跑偏、调用成本等等。

所以多 Agent 并不是越多越好。

只有当一个角色真的拥有独立责任、独立输入和独立验收标准时，拆出来才有价值。

这些问题也需要在真实使用过程中不断调整。

讲到这里，其实也基本接近尾声了。

我有一个很真实的感受。

公司里这套 Harness 能力每往前走一步，我有时候心里反而会多一层担忧。

因为越接近一线，越能够看到这套东西未来可能产生的影响。

有时候我也会忍不住想：

未来真的还需要这么多人吗？

毕竟我自己也是一个职场人，看到这些变化，不可能完全没有感触。

但是没有办法，时代一直在往前走。

我们能做的，还是尽量跟上变化，一起迭代，一起进步。

所以最后想聊一个我觉得挺重要的问题：

当 Harness Coding 真正能够在生产环境落地以后，相比传统软件研发，它对人、组织和基础设施到底会带来什么变化？

这一页其实也是毛剑老师之前建议我可以展开聊一下的内容。

我自己的第一个感受是：

AI 时代，对人的要求其实反而更高了。

但这里的“高”，不是说每个人都必须去钻研更底层的源码，或者掌握更多冷门技术。

我有时候会开玩笑说：

AI 时代可能反而更适合那些“眼高手低”的人。

这里的“眼高手低”，我其实是当褒义来理解。

以前你有一个想法，想在公司里推进，但是没资源、没人力、优先级又不够高。

那很多时候只能算了。

现在不一样。

你有一个想法，可以先让 AI 帮你快速做出来。

如果这个东西真的有价值，你就有机会拿着一个已经能够运行的结果，去证明这件事情值得继续投入。

所以 AI 时代，对于研发人员的主观能动性要求其实更高了。

除了主观能动性，还需要足够的好奇心。

要愿意去了解新东西，愿意持续尝试，愿意不断更新自己的工作方式。

这个时候我也挺推荐大家，平时有机会可以写写文章、做做分享。

把自己做过的东西整理出来，把好的实践分享出来。

这个过程本身其实就会形成一个比较正向的反馈循环。

人普遍都是有惰性的。

主观能动性、好奇心、持续学习，说起来很简单，但真正长期做到并不容易。

这是我觉得 AI 时代对人的要求。

而对于组织结构，我觉得也会逐渐开始围绕 Agent 重新调整。

当越来越多工作可以由 Agent 跨技术栈完成以后，今天非常明确的“前端工程师”“后端工程师”“车端工程师”这些标签，未来可能会慢慢变得没有现在这么绝对。

因为 Agent 本身可以同时理解前端、后端甚至车端。

人的价值会越来越往另外几个位置移动：

定义目标。

提供关键上下文。

审核阶段性结果。

承担最终交付责任。

但这一块，我觉得很多成熟组织其实还没有完全准备好。

因为现有组织本身就有岗位、流程、汇报关系和历史包袱。

反过来，一个新的团队或者新的公司，因为没有那么多既有的结构，反而可以更自然地重新设计人与 Agent 之间的协作关系。

所以我觉得，这也是这个时代比较有意思的地方。

新的组织、新的个体，都有机会借助新的工具，比过去更快地做出以前需要很多资源才能完成的事情。

这其实也是属于我们每个人的机会。

> 作者：贾克斯的平行世界