DeepSeek Harness发布之后，网上最热闹的问题，是它为什么没有一个更好用的CLI，它能不能替代Codex、Claude Code，或者它是不是另一个Pi。
这些问题都合理，但它们盯错了地方。
就像蒸汽机刚出现时，人们只讨论它能不能装回原来的水车。大家仍在比较入口、按钮和使用习惯，却没有意识到：变化不在水车转得更快，而在动力终于可以离开河道，进入工厂。
我一开始也看错了。
最初打开DeepSeek Harness的页面时，我把它理解成了一个新的Agent产品。继续追问MCP、Skill、Agent SDK和Harness分别在做什么，我才意识到，重点已经转向了另一个层面：它把构建企业专属AI运行系统所需的运行层，以开源、插件化的方式摆到了更多人面前。
这改变了问题本身：我们不必只讨论该买哪一辆“车”，也可以开始讨论，企业能不能参与定义自己的造车平台。
大家争论的是产品，DeepSeek开放的是运行层
过去两年，大多数人接触Agent，都是从一个已经做好的产品开始。写代码用Codex、Claude Code，做复杂任务用Manus、Genspark，做工作流用n8n、Coze。国内读者现在还有一个更现实的参照：腾讯云WorkBuddy。腾讯把它定位为面向普通职场人的AI工作台，用户可以直接在对话中完成资料处理、研究、内容和办公交付，也提供面向企业管理与多Agent协作的版本。
这些都是已经完成产品设计的“整车”。它们把模型、工具、界面和运行机制封装起来，让用户打开就能工作。久而久之，我们习惯把Agent理解成“聊天框加工具”，评价新东西时，也先看界面顺不顺、命令行强不强、装了多少插件。
可企业把AI放进业务后，难点马上转向持续执行。
难的是：模型能不能读懂任务状态，能不能调用正确工具，失败后从哪里恢复，哪些动作可以自动做，哪些动作必须审批，结果能不能回写，过程能不能追溯。
聊天框只是入口。入口下面的运行机制，才决定Agent能不能进入真实业务。
DeepSeek官方给出的公式很直接：Agent = Model + Harness。官方页面同时写明，模型、工具、技能、会话、沙箱、存储、循环、调度和UI都可以由插件组合；Cordis内核只负责插件加载、卸载和依赖关系。
换句话说，DeepSeek开放的是一套可以组装不同Agent产品的运行平台。
如果沿用汽车的比喻，模型更接近发动机，Harness更接近底盘、控制系统与装配体系，而Codex是一辆已经完成设计、调校和服务封装的整车。一边是完整产品，一边是生产产品的基础设施，评价尺度自然不同。
通用工具提升个人，企业需要自己的运行方式
我是在追问一个很朴素的问题时想通这件事的：企业已经有MCP Server和Skill，为什么还需要Harness？
答案很清楚：MCP、Skill与Harness分处不同层。
模型提供理解与推理能力；MCP像标准插座，让Agent接上企业系统；Skill像一套工作方法，告诉Agent这类任务应该怎样完成；Harness则负责把模型、工具、方法、状态、权限和执行过程组织起来。
只有MCP和Skill，企业得到的是一套“能被Agent调用的能力”。员工仍要打开Codex、Claude Code或其他产品，再借用这些产品的运行机制完成任务。
Codex、Claude Code、WorkBuddy、Manus这一类成品Agent依然很有价值。Codex和Claude Code更偏开发工作；WorkBuddy面向国内普通职场人，使用门槛和可获得性也更贴近中国企业。它们承担的共同角色，是把复杂的Agent能力包装成用户可以直接使用的产品。
WorkBuddy Enterprise也说明，成品Agent并不只服务个人，它同样可以继续向企业账号、权限共管、统一管理和Agent生命周期扩展。企业因此有两条现实路线：购买一套成熟产品，快速覆盖更多员工；或者掌握可定制的运行层，围绕自己的业务对象、数据口径、审批链和责任边界打造专属Agent。前一条路启动更快，后一条路拥有更大的定制与控制空间，两者也可以同时存在。
企业日常工作还会提出一组更具体的要求：普通员工只看见自己负责的业务对象，只能调用岗位允许的动作，关键节点自动进入审批，结果回到统一记录里，异常还能找到责任与恢复路径。
成品产品可以接入企业工具，也能通过企业版逐步增加管理能力，却无法天然预装每家公司的岗位分工、业务状态和风险边界。企业把MCP和Skill接进成品产品之后，员工仍要进入对方设计的工作环境，组织也要在产品能力与自身流程之间做取舍。它能显著改善个人生产力；当企业希望AI进一步成为组织的默认执行系统，权限、审计、界面和流程就会成为新的设计对象。
我现在会把企业AI应用分成三个阶段。
第一个阶段是“知识助手化”。企业给员工配通用AI工具，或者接上内部知识库，用来检索资料、回答问题、写作和分析。AI知道得更多了，工作怎样流转并没有改变，效果也很依赖员工个人会不会提问。
第二个阶段是“AI节点化”。企业把模型放进n8n、RPA或现有业务系统，让固定环节自动生成、分类和总结。AI开始执行任务，但负责串联各个节点的仍是预先写好的流程；遇到计划变化、数据缺失和运行异常，人还要回来接管。
第三个阶段才进入“Agent驱动”。Agent读取业务目标、实时状态和权限边界，判断下一步调用哪项能力；普通异常在授权内处理，高风险事项带着原因、影响和回滚方案升级给人。工作流程由数据和事件持续推动，AI开始参与组织、协调与复盘。
前两个阶段都能创造价值，企业的分工、交接和责任结构却基本保持原样。走到第三阶段，AI才开始改变组织怎样完成工作。
有了可定制的Harness，企业才有机会把同一套能力变成自己的Agent产品：网页工作台、App，或者隐藏在业务系统里的任务助手。企业保留自己的流程、数据与治理规则，自己决定Agent看见什么、能做什么、何时停下、由谁批准、失败后怎样恢复。Codex等通用工具仍可用于开发、调试和维护，却无需成为所有员工的日常入口。
一条卡住的内容生产线，让我看见自动化的天花板
这个判断并不只来自架构图。我手里正好有一条内容生产流程：员工在任务表里审核脚本、修改状态，工作流收到信号后自动生成视频。顺利的时候，整条链路看起来已经很自动化；一旦卡住，任务表里往往只剩下一条技术报错。
员工不知道问题出在素材、模型、工作流还是最终质检，也看不懂报错意味着什么。最后仍要由我打开Codex，连接工作流和服务器，查日志、找原因，再决定是补数据、重试，还是修改流程。
我由此意识到，这条管线已经会自动执行，距离“懂得如何完成工作”仍差一层。它会跑固定步骤，却不理解自己为什么停下；它会留下错误，却不会用业务语言解释影响；方向发生变化时，也无法根据目标和权限自己调整任务。
如果只增加MCP和Skill，我当然可以让Codex更方便地读取这条生产线、调用工具、帮助排障。但员工依然需要借用Codex的运行机制，企业也依然没有一个面向自身业务的Agent产品。
Harness对我开始变得具体，是因为另一种工作方式出现了：员工只面对自己的任务工作台。视频失败后，他可以直接问“卡在哪里，能不能处理”。Agent读取运行状态，在权限内补数据或安全重试；涉及工作流、预算或发布权限的变更，则先整理原因、影响、测试和回滚方式，再提交给负责人审批。
同一套业务能力没有改变，变化发生在状态理解、工具组织、例外处理和权限升级这一层。固定工作流无法承担这些判断。
AI原生会改变工作的默认分工
不少企业今天做的AI化，仍停留在给旧流程增加一个模型步骤。原来人工写文章，现在模型写；原来人工填表，现在模型填；原来人工整理数据，现在模型总结。效率会上升，但任务仍靠人逐步发起，异常仍要管理者亲自处理，系统之间仍靠固定规则传递。
AI原生对应的是另一种分工：人设定目标、边界和验收标准，Agent在授权范围内持续执行；数据变化、审核完成或运行失败自动触发下一步；普通问题由Agent处理，超出权限的例外整理成审批请求交给人。
人的角色也随之变化：减少逐步操作，把精力放在规则制定、目标负责和高风险决策上。
更进一步，一线员工发现原定方向已被数据否定，也不必先找管理者，再由管理者打开技术工具逐条修改任务。员工提出调整，Agent读取目标和历史结果，在预算与权限范围内停止未开始任务、补充新测试；超出边界的变化再交给人决定。
这也解释了企业为什么会需要A2A。企业所需的A2A更像一套结构化交接：策划Agent提方向，创作Agent产内容，质检Agent做判断，执行Agent只在授权范围内操作，复盘Agent给出下一轮取舍。越界就升级给人，每一步都留下记录。
DeepSeek官方强调，系统提示、工具调用、子Agent调度和上下文注入都会进入仅追加的会话日志，恢复、分叉、检索与回放共享同一事件流。官方没有承诺它已经替企业解决A2A治理；但这种“运行有迹可循”的结构，正是多Agent从演示走向企业协作需要的底座。
为什么营销会最早感受到变化
营销天然适合验证这种工作方式，因为它拥有持续反馈：内容有没有曝光，用户有没有互动，线索有没有产生，投放有没有转化，生产和履约成本是否合理，这些结果都会影响下一轮决策。
过去的效果广告已经证明，只要目标清楚、反馈及时，系统就能围绕结果调整触达和预算。但效果广告通常只优化一个局部目标。卖得多，不等于利润高；某个平台转化好，不等于生产端承受得住；短期互动高，也不等于品牌方向正确。
当Agent能够读取内容、渠道、成本、产能与转化数据时，企业才有机会从“单点投放优化”走向“多目标经营判断”。它不只判断哪条广告应该加预算，还要判断什么内容值得继续生产，哪个渠道应该降低频率，哪类产品虽然好卖却不值得扩大，哪些异常需要人立即介入。
模型负责判断，MCP连接数据与系统，Skill固化方法，Harness让这些能力在权限、状态和事件的约束下持续协同。
如果这套机制跑通，营销系统就不再只是任务列表，而会更接近一个受治理的AI营销员工：发现任务、组织创作、推动审核、执行分发、回收结果，再提出下一轮建议。
别急着谈颠覆，先验证一个小流程
看到这里，很容易得出另一个过度乐观的结论：从此非技术人员也能一键做出企业Agent。
这同样不准确。
DeepSeek Harness仍处于开发者预览阶段，官方明确提示核心插件和基础API会持续迭代，兼容性会发生变化。账号体系、数据隔离、密钥管理、费用控制、审计、测试、回滚和长期运维，也不会因为“一切皆插件”自动完成。
Harness降低了构建运行层的门槛，工程责任依然存在。
企业更合适的起点，是挑一个结果清楚、反馈够快、风险可控的小流程。品牌和营销负责人可以先问三个问题：
任务能不能验收？如果连“完成”和“做好”都无法定义，Agent只会把模糊放大。
数据与权限是否分清？Agent可以读取什么、修改什么、花多少钱、何时必须停下，需要在上线前写明。
自动与审批的边界在哪里？低风险动作可以自动推进，高风险变更必须留下原因、影响、测试和回滚方案。
先让Agent在历史任务上判断，再允许它提出建议；建议稳定后，再开放安全重试；证据充分，才进入真实执行。每一步都用完成率、恢复时间、人工介入次数和成本变化判断是否值得继续。
这比做一个看起来无所不能的聊天窗口，更接近企业需要的AI化。
当业务开始参与定义运行层
DeepSeek Harness今天仍是一套快速变化的Agent运行平台与装配体系，距离开箱即用的企业产品还有一段路。
但它把一个重要问题摆到了更多企业面前：过去，模型掌握在模型公司手里，Agent产品掌握在技术平台手里，业务团队只能购买成品，再适应产品边界。现在，企业开始有机会围绕自己的流程、数据、权限和验收标准，定义属于自己的Agent。
这件事的价值落在企业的自主定义权上。每家公司无需复制Codex，每个员工也不需要一个无所不能的数字分身。
它打开的是另一条路：让懂业务的人主导Agent要完成什么，让专业团队负责系统怎样安全运行，让人在目标和治理的位置上工作，让Agent成为默认执行单元。
所以，别再问DeepSeek Harness为什么不像Codex。
更值得问的是：当Agent的运行层开始变得可组合、可改造，你的企业有没有一个值得先交出去、又能够验证结果的真实流程？
当一个组织能把目标、权限、证据、审批和异常处理写进Agent的工作方式，AI才不再只是旧流程里的一个功能。工具会一直变化，今天叫Harness，明天可能有别的名字；企业真正要掌握的，是把自己对业务的理解、对风险的判断、对责任的划分，沉淀成一套可定制、可验证的运行方式——这件事，不会因为任何一款产品的迭代而过时。