Harness时代AI优先组织架构从信任人到信任AI的转变

你准备好迎接AI主导的时代了吗？

“Harness Engineering”（驾驭工程）正成为硅谷技术演进的新范式，Anthropic、OpenAI等领军企业都在深入探索。然而，其核心精髓仍未被广泛理解。近期，一篇题为《Why Your “AI-First” Strategy Is Probably Wrong》的文章在X平台引发百万级热议，作者是硅谷初创公司CreaoAI的联合创始人Peter Pang。他分享了基于Harness范式构建的智能体（Agent）系统带来的颠覆性效率：99%的代码由AI生成，日均进行3-8次生产部署，过去耗时六周的产品流程如今压缩至一天内完成。

这场变革带来了深刻洞察：在Creao，市场团队不再疲于追赶开发进度，因为后者的迭代速度已远超市场需求；当AI接管了大量对齐（Alignment）工作后，移除传统产品经理角色反而提升了团队整体效能；初级工程师往往比资深者更能适应AI驱动的转型；尽管部分过往专长在快速贬值，但资深工程师的核心价值并未消失，而是发生了迁移——未来的关键能力可能不再是编写代码，而是“洞察AI规划中的缺陷”与“精准判断何为真正有价值的需求”。

01 Harness工程深度解析：如何极致释放大模型潜能

究竟什么是Harness Engineering？这一概念可追溯至大模型兴起初期。当时业界热议提示词工程（Prompt Engineering），随后演进至上下文工程（Context Engineering），焦点始终局限于如何与模型本身交互。

但Harness的范畴远不止于此。它关乎如何系统化地“驯服”一个通用人工智能。因此，它涉及工具链的整合、沙箱架构的设计、宿主服务间的交互机制、安全保障、沙箱启动优化、延迟控制等全方位工程。可以说，Harness的工程水平直接决定了大模型潜力发挥的上限。

一个鲜明的对比是：一个设计精良的Agent可以在一夜之间完成三人团队的SEO工作流；而一个设计不当的内容流水线运行两天，产出却可能全是低质内容。这其中的巨大差距，正是Harness成败的关键体现。

那么，Harness的本质是什么？核心在于构建一个能够持续进化的系统。当系统产出未达预期时，它是依赖人工干预调整，还是能够自我诊断、自我优化？这正是Harness要解决的根本问题。

Harness的一项重要使命是让Agent在推理阶段实现有效扩展，包括为其提供更丰富的上下文与工具链，使其能进行更长时间的“思考”并处理更复杂的任务。此阶段若Harness设计不佳，极易导致模型产生幻觉或上下文溢出，致使能力降级。因此，构建一套高效的Harness是一项复杂且需要深厚经验的工作。

目前市场对Harness存在哪些共识与分歧？一个常见误解是将其视为静态的——仅仅是一套辅助LLM发挥作用的配套系统。但更前沿的观点认为，Harness是一个动态演进的过程。关键在于系统如何从静态“激活”，实现自我优化，并持续、敏捷地响应来自市场、产品与用户的各类信号，从而不断迭代。而这个迭代过程本身，就应由AI主导，人类需要做的，是将各类信号高效地“输入”给AI系统。

02 从六周压缩到一天：AI驱动开发流程的极限速度

在Creao的实践中，Harness分为两部分：一是对自身Agent系统的驾驭，二是帮助用户驾驭他们自己构建的Agent。传统开发中，迭代一个功能可能需要两三个月，而AI辅助编码可能一两小时就能产出原型。如果后续仍沿用漫长的设计和测试周期，就显得本末倒置。因此，如何将设计、规划、测试全面整合到Harness流程中，是企业能否真正转型为AI原生的关键。

这里需要明确一个核心观点：要达到真正的AI-First或AI原生状态，绝非简单地在现有流程上叠加AI工具，而是必须围绕AI的核心能力，彻底重构工作流程与组织形态。

起初，Creao也经历过每个成员各自为战使用AI工具的阶段，结果效率并未提升，反而因为工作节奏不一，导致远程协作下的对齐成本飙升。于是，他们开始思考：如何才能让AI在公司运营中真正实现自动化运转？这才催生了Peter设计的新开发流程、架构，以及文章中提到的具备自我修复能力的Agent Harness系统。

重塑组织架构，首要挑战是人的观念——团队能否接受全新的工作模式。这需要花费大量时间对齐认知。幸运的是，在AI的辅助下，这一转型过程被大大加速。可能只需一两周，就能完成对整个系统（包括前端、后端、架构、基础设施）的重构，并向团队展示其在部署频率、可靠性与最终效果上的显著优势，从而快速凝聚共识。

许多人的思维难以转变，认为用AI提升个人效率就已足够。但AI-First要求的是，让AI来驱动公司的整体方向，甚至每日的工作节奏都由AI主导。这完全是两个维度的概念。如果只把AI视为工具，使用者的效率提升可能存在天花板（例如10倍）。但如果期望效率提升100倍、1000倍，就不能再将自己定位为工具使用者，而必须让AI成为所有生产力的主导者。人的角色将转变为：复盘结果优劣，并以新的方式与系统协同。这是许多企业在转型时未能意识到或难以跨越的关键一步。

那么，系统如何与人配合？核心在于建立信任。传统团队开发的巨大痛点在于信息同步与对齐，任何环节的信息遗漏都可能导致偏差。在AI-First模式下，对齐工作由AI主导。例如，AI会主动告知市场团队工程师即将发布的功能，市场团队无需反复追问。

AI如何预知工程师明天能完成工作？在AI的思维模式下，产品迭代更关注新功能能否提升产品的核心指标，或者是否有真实的用户行为数据支撑。因此，核心是搭建完整的数据反馈链路。之后，将由Agent根据这些数据自主决策：这个功能是否真的有用？是否要上线？或者是否需要回滚？

这意味着，工程师提交代码后，无需手动通知“已完成”。AI会自动根据代码质量、进程状态等做出判断。这类似于传统的CI/CD流程，但规则驱动升级为了AI驱动。例如，现在常用的Playwright可以进行AI驱动的端到端测试，确保发布的代码没有破坏性缺陷。代码发布后，日志中的错误或事件也会成为信号反馈给AI，用于评估代码质量。

关于代码质量，一个现实是：Bug在工程中不可避免，无论代码由AI还是人编写。Harness不是一个静止的、无需维护的完美系统。它的核心价值在于能否快速发现并修复系统中的Bug。

第一步，在CI/CD流程中，通过一系列回归测试，防止Bug进入生产环境。第二步，即便某些边界情况或竞争条件漏网，也要能以最快速度识别并修复。传统上，这两步都依赖人工。而在Agent Harness中，则由Agent系统驱动。Creao开发了Agent驱动的CI/CD系统和Bug定级系统，能自动对问题进行分类并指派给工程师修复。

效率提升有多大？由于许多流程由Agent驱动且可并行，识别一个Bug仅需1-2分钟，指派给工程师仅需几秒。工程师再利用Agent调查并提出修复方案，整个周期大约1-2小时。相比之下，过去识别、修复并发布一个Bug，可能需要一周时间。

更直观的变化是，以前困扰团队的“功能愿望清单”和“Bug修复清单”之争消失了。Bug被即时发现和修复，而新功能的数量已经多到远超市场需求。目前，超过50%的问题是通过自动修复系统完成的。对于低风险目录下的修复，AI会自动提交拉取请求，工程师只需简单批准即可发布。

03 架构师：Harness体系中的核心决策者

一个常见的担忧是：如果AI搭建的技术框架在底层存在严重问题，工程师是否需要重新学习整个系统才能解决？

这就引出了AI时代工程团队的两种关键角色：架构师和操作者。架构师在系统搭建过程中的作用至关重要。例如，整个Agent的架构、沙箱与宿主服务间的交互设计，仍然需要架构师来决策。如果AI直接通过编码给出一个解决方案，这个方案通常可能存在安全隐患或性能延迟问题。如何优化整个系统，依然依赖于架构师的判断与经验。

区别在于，传统搭建一个Agent团队可能需要10到20人，而现在，搭建整个系统可能只需要一位架构师，在一周内就能完成核心框架。

这里需要一个根本性的观念转变：我们要把AI视为一个“系统”，而非单纯的“智能体”。当系统出错时，目标不是去纠正这个智能体，而是去弥补和完善这个系统。这是Harness与当前普遍认知最不同的地方——它是一个动态的优化和提升过程，不是用静态的枷锁去束缚智能，而是为其提供成长空间与规则边界，就像培育一个生命，让它在规则内变得越来越好。

这个观点衍生出一个更激进的思考：我们未来生产的内容，其受众可能不一定是人。例如，一份市场物料从人的审美看或许不佳，但当它投放到市场，阅读它或分析它的可能是一个Agent，而反馈回来的数据却可能证明其转化效果更好。未来，购物、信息筛选等决策可能都由Agent完成。那么，广告是发给Agent看，还是发给人看？必须搞清楚工作成果最终被谁消费，才能决定是优化系统，还是回归到原始的人工流程中去修补错误。

从另一个角度看，SaaS产品也在快速转型。过去，SaaS产品需要一个给人查看和管理的仪表盘。而现在，团队在使用任务管理工具时，更关心的是Agent能否“看到”并优先处理这些任务。因此，他们会评估这些产品是否提供了更好的模型上下文协议和API供Agent调用。

许多公司在考虑AI转型时，第一个顾虑就是：使用AI后仍需人工复核，时间和成本与人工操作无异。但如果真的构建起AI系统并仔细核算，会发现效率提升是巨大的。关键在于整个团队要有共同目标。只要有人觉得“还不如人来做”，改造周期就会被无限拉长。这是大多数企业在组织层面面临的核心挑战。

04 转型最艰难的一步：从信任人，到信任系统

Creao也并非从一开始就是AI-First。整个公司经历了一个认知演进过程：必须认清谁是未来生产力的核心。2025年上半年，大家仍认为AI是辅助人的工具，人占主导地位。但到了下半年，他们意识到，如果维持现状，企业效率的提升将非常有限。核心问题在于没有将生产力的主要使用者从人转变为AI。这种转变需要时间，市场团队和工程团队甚至花了一两个月反复探讨什么才是更好的工作方式。

这种角色转变也与AI能力的提升密切相关。过去一年，AI从辅助角色，到参与开发，再到如今能够相对主导开发过程，每一步都伴随着基础模型能力、Agent架构和基础设施的飞跃。一年前，从技术上让AI主导开发还不现实，但在重构过程中，当AI能力达到某个临界点时，整个重构的速度和效果远超一年前的想象。

意识到需要重构是在去年八九月份，花费最多时间的是转变团队思维。真正开始重构代码架构和开发流程是在今年1月，大约用了两周时间，重构了包括现有产品在内的整个架构。

那么，有哪些过去AI解决不了的问题，现在被解决了呢？关键在于规划阶段。以前，AI可能只能给出50分的方案，需要人工大幅修改。现在，它能给出90分的方案。当看到这个规划时，人可以提出批评意见，AI便能给出修订版，而无需人工直接修改规划。

AI写代码的能力是否已超越人类？至少从2026年开始，Peter本人就没有再写过一行代码。但从规划能力上讲，作为架构师的价值，恰恰在于找到AI规划的缺陷。当前AI的规划仍存在不足，例如可能存在安全或延迟方面的缺陷。架构师需要凭借经验去评判和质疑它，从而推动其进一步优化。

这个过程正是Harness的核心。例如，将安全性设计准则教给AI后，可以将其固化成一个“技能”。下次遇到类似情况，只需引用这个技能，而无需重复具体的指令。团队所有工程师都可以参考这个技能。

AI作为生产主力，其效能相当于多少员工？对比一年前非AI主导的模式，要研发Creao当前这样的产品，估计需要一个百人左右的团队，花费四五个月。而目前，公司仅25人，工程师团队不足10人，产品第一阶段的部署只用了大约两周。

从SaaS公司运营的角度看，变化更为直观。传统软件时代，销售团队的概念往往超前产品4-5个月；而现在，情况反过来了，技术团队反过来超前市场团队4-5个月，市场团队在拼命追赶开发的功能。这导致整个运营和组织结构都可能与过去截然不同。

市场拓展方面，团队也在使用自家产品构建AI-First的工作流。当然，这其中挑战不少。最大的困惑在于：工程成果相对容易评估，有明确的指标；但从市场进入的角度看，无论是写文章还是做视频，每个人对价值的判断都相对主观。如何构建一个系统，将这些主观判断转化为有效的信号，让系统能够自动运转，是一大挑战。目前并非100%由Agent决策，而是会产出大量Agent结果，再由人判断好坏。他们有很多功能，但如果认为市场尚未准备好，就不会贸然推出。

05 为何大企业难转型？中小企业的AI红利窗口

有哪些超前的思想是市场尚未完全接受的？一个相对大胆的实践是：每个员工的Agent都拥有读写所有数据的权限。为了让组织更高效，很多数据应该向Agent和每个人开放。但这需要更好的技术支持，包括如何限制个人或Agent的权限，确保Agent在读取数据时不会出错。例如，以前要问“Peter，今天我们有多少用户有某种行为”，可能需要找数据或工程师同学帮忙搭一个新表格。而现在，只需向Agent提问，3秒钟后就能得到答案。

当前的主要挑战，或许不是市场能否接受这种工作方式，而是市场根本不知道这种工作方式的存在，或者不知道如何高效地使用Agent来完成工作。因此，Creao做了大量工作，让用户无需复杂设置，就能更容易地访问Agent，协助完成工作。

那么，Creao对标的场景和主要客户是谁？答案是都会涉及。但真正的目标，是那些中小企业。因为它们可能是最早采用AI的群体。企业规模越大，合规问题越多，“人”的因素也越复杂，导致整个转型过程异常艰难。相反，如果一家公司没有太多合规负担和历史遗留系统，它可能就是最容易进行这类转型的第一批公司。

公司想要成功转型，创始人是否必须拥有坚信AI的核心信念？更多在于，他们必须想清楚转型最终意味着什么。例如，2023年大模型刚出现时，很多SaaS公司想的是如何把AI做成一个功能集成到现有产品里。这本质上可能没搞清楚：如果你的产品架构本身不支持集成最新的AI能力怎么办？因为你的数据库可能不符合要求，交互方式也可能不是未来的方向。因此，你可能需要的是整体产品的重构。如果接受不了这个结果，转型就很难推进。

06 当AI主导生产，人类的新定位是什么？

组织结构具体发生了哪些变化？首先，是信任基础的改变。原来组织信任的是人，现在引入AI后，首先要解决的是：能否信任AI做决策或执行任务？这种信任，正是为什么需要构建Harness系统的原因——必须设置足够的“护栏”和机制，来确保AI在决策、规划和执行中的所有工作，最终是值得人信赖的。

接下来是具体岗位的变化。例如，公司不再设立单独的产品经理角色，其职责被分解到了每位工程师和像Peter这样的工程管理者身上。这并非认为产品经理岗位不重要，而是因为这个角色通常是矛盾最集中的点，需要同时与市场和开发沟通。大量的对齐成本都发生在这个角色上。当移除这个角色后，对齐成本有时反而可能降低。

未来还需要产品经理吗？很可能需要。但未来的一种可能是，产品经理的许多权力会分散到开发团队的各个成员身上。如果每个开发成员在AI的帮助下都能更好地具备产品思维，那么这个职位的必要性本身就会下降。因为产品经理原本解决的主要是对齐成本和如何降低开发成本。

可以这样理解：现在工程师团队某种程度上扮演了产品经理的角色。但反过来，一个优秀的产品经理对市场和产品也很有想法。加上如今开发成本极低，他或许能很容易地通过AI的执行能力，快速将想法变成产品，甚至不需要庞大的工程团队。因此，这两种角色正在某种程度融合。这个角色到底由技术团队还是产品团队来担当，已不再重要，因为主导者是AI，想法本身才更关键。

未来的产品成功，可能不再依赖于某个产品经理或灵魂人物的个人英雄主义，而更可能是一个组织共同打造了一个受市场欢迎的产品。

一个明显的趋势是：复合型人才或通用型人才，在AI环境下将成长得更好。无论是具备产品感和市场感的工程师，还是拥有实现能力的产品经理，都会非常重要。另一个趋势是：UX/UI设计师会变得非常重要，但他们需要具备将想法落地到产品中的执行能力。如果你需要把想法传递给另一个人，那么交流或对齐的成本，可能远大于执行的成本，这在AI工作环境下就显得不那么高效了。

为什么初级工程师比资深工程师更能适应AI环境？因为初级工程师的技术债务或思维束缚通常较小，他们更能接受扩大自己的工作范围——不仅是写代码，还要融入产品设计，并在功能部署后进行分析，根据分析做出判断。

而资深工程师往往更加专精。例如，一个专注于基础设施或后端的人，在传统工作环境中可能不关心代码发布后发生的事情。但在AI环境下，工程师的职责范围需要大大扩展，不再只是写完代码就结束，还要在写代码前加入自己的判断，在发布后评估其影响。初级工程师通常更能接受这种工作状态。如果要求一位资深工程师除了写完代码，还要负责后续过程，他们可能难以理解或快速转变思维，对齐成本要高得多。

作为一名高级工程师或某个领域的专家，在过去十年的软件开发中积累的知识非常有价值，因为你知道如何写出最简洁的代码、设计最好的架构，这可能需要两三个月时间。但AI编程能力已经很强，未来只会更强，这会使个人的某些专长价值相对降低。许多人难以接受的是，自己花了10年、20年学到的知识，在未来可能不再那么重要。

那么，现在更倾向于招聘哪类人？虽然转变一位资深工程师的思维可能比转变初级工程师更难，但从价值上看，一位资深工程师的价值目前是无法被取代的。因此，如何找到一位既能拥抱AI思维模式，又具备产品感知和市场知识的资深工程师，虽然非常困难，但对公司而言价值巨大。好处在于，过去我们需要很多这样的人，现在可能只需要一两个就够了。

当AI成为主力，并能迭代产品，一切都在动态变化时，未来人类最核心的能力是什么？从工程师角度看，最需要的是系统架构能力。角色从“实现功能”转变为“如何架构和维护AI系统”。从市场角度看，做市场进入的核心过程，也变成了搭建一套能够自主运行的Agent市场系统，而不仅仅是生产市场内容。

如果从更长远的角度看，正如整个技术发展史所揭示的，确定技术发展方向永远是基于人类和社会的需求。只要人类这个物种还存在，定义需求的方向和审核最终结果的价值，就是无法被取代的。