绝大部分 agent 项目在拿到业务正反馈之前，就被耗死在了手搓 agent harness 这些基础设施上。
很多人第一次被 AI 写代码震撼，都是因为 Cursor 或 Claude Code。你让它修一个 bug、重构一个模块、加一个功能，它真的会去读相关文件、跑测试、看报错、回头改。整个过程行云流水，让你感受到 AI 真的开始替代初级工程师了。
然后你很快会冒出第二个念头：它底层用的不也是 Claude 吗？我也有 Claude API。我是不是自己也可以做个 agent 来解决我的业务问题？
两周之后，你做出来一个磕磕绊绊的东西。它有时候会调工具，有时候卡住不动。聊几轮 context 管理又出了问题。
大家都有一样的模型，但是 agent 效果却天差地别。
接下来很多人会犯第二个错误：以为问题出在 prompt 没调好，RAG 没做好，或者是需要加个记忆模块。于是花一个月调 prompt、加向量检索、在 Opus 和 Sonnet 之间来回切。
效果比之前好了一些，但距离面向业务落地还差得远。
问题其实出在了模型和你的应用之间那一层。也就是现在在 AI 行业越来越频繁讨论的术语：agent harness。
一、Agent 的工程边界
要理解 Claude Code 和你的 agent 之间的差距，得先把 LLM、agent harness、agent 这三层拆开。
LLM 是大脑。
它只能输入文字、输出文字。跟用户之间智力问答。你让它"读一下这个文件"，它自己做不到。你让它"运行这段代码看看输出"，它自己也做不到。你让它"等 5 秒再继续"，它甚至没有时间概念。它没有天然记忆，每一个会话都是从零开始。
世界上最聪明的大脑，如果从颅骨里拿出来放在桌上，什么也干不了。
Agent harness 是身体和神经系统。
它是大脑的手脚，为大模型提供了元能力。大脑说"我要看一下这个文件"，harness 会去读文件系统，把内容塞回下一轮输入。大脑说"我要跑一下测试"，harness 会运行一个临时 sandbox 执行命令，捕获 stdout 并回填结果。大脑说"我要等 30 秒再继续"，harness 会执行 sleep 命令。
具体到生产级系统，一个 harness 至少要包含：
- 模型客户端（和 LLM API 通信、重试、成本控制）
- Context 组装（这一轮喂多少历史、压缩什么、保留什么）
- 工具系统（定义工具、调用工具、并发执行、处理失败）
- 执行环境（沙箱、文件系统、网络访问）
- 状态和记忆（会话状态、长期记忆、checkpoint）
- 调度循环（什么时候继续、什么时候结束、什么时候反思）
- 身份和权限（这个 agent 代表谁、能动什么）
- 可观测性（每一步记录、replay、debug）
- 安全策略（拦危险操作、防 prompt injection）
- API 接入层和部署基础设施
如果我们把 agent 看作新的软件范式，这些就是保证 agent 稳定性的基础设施。
Agent 是有职业的人。
大脑 + 身体 + 一套针对特定工作训练出来的技能、知识、流程和判断标准，才构成一个真正的 agent。律师是一种 agent，会计师是另一种 agent，外科医生是第三种 agent。他们共享同样的人类生理结构，也就是类似的 LLM 和 harness，但因为业务场景、领域知识、可用工具、成功标准完全不同，最后变成完全不同的职业。
放到 agent 世界里也一样。一个销售 agent 和一个客服 agent，可能底层用同一个 Claude，跑在同一种 harness 上。但它们的产品形态、业务逻辑、领域 prompt、连接的 CRM 或工单系统，这些"职业差异"，才最终决定了它们能否为用户提供价值。
这三层一拆开，你会发现一个非常常见的误解：很多人以为做 agent = 模型能力 + 一点 prompt 工程。这套理解漏掉了中间整整一层 harness。而恰恰是这一层，决定了你能不能把模型的智力真正变成可用的产品。
二、为什么 Claude Code 行，你的 agent 不行
同样是 Claude，为什么 Claude Code 让你觉得"AI 真的可以替代初级工程师"，而你自己用 API 搭出来的东西让你觉得"AI 还差得远"？
答案是：Claude Code 赢在 harness。
上下文管理。
当你在 Claude Code 里让它"修一下这个 bug"，它知道当前打开的是哪个文件、最近编辑过哪些文件、git 里有哪些未提交改动、相关依赖文件是什么、终端里最近一次报错是什么。这些信息都是 Claude Code 的 harness 在每一次请求之前帮你组装好的。
你写 demo 的时候，多半是把整个项目目录塞进 prompt 里。结果模型很快被无关上下文淹没，开始犯各种低级错误。
工具边界。
Claude Code 的"编辑文件"，不是让 Claude 生成一个完整新文件然后覆盖原文件。这种做法在文件超过几百行必然失效。更合理的方式是一套精心设计的 diff 应用机制：模型只输出结构化补丁，harness 负责把补丁干净地打到真实文件上，并且在补丁失败时回滚。这套机制本身就是 harness 设计的核心 IP，不是模型能力。
错误恢复。
测试跑挂了，编译报错了，lint 警告了，类型检查失败了，Claude Code 会自动把这些反馈塞回模型的下一轮输入，让它继续修。这是 orchestrator 的能力。模型本身并不知道自己刚才那一步引发了什么后果。是 harness 把"后果"翻译给它。
模型路由。
看似简单的一次"修 bug"，背后可能调用了几个不同模型：轻量模型做意图识别和文件检索，中等模型生成 diff，更强模型做复杂推理。什么任务路由到什么模型，是 harness 在决策。
隐性的 prompt 工程。
Claude Code 每次发给模型的 system prompt、工具描述、few-shot examples，是大量工程投入反复打磨的结果。同样的模型，喂给它精心调过的几千字 system prompt，和喂给它一句"你是一个编程助手"，效果当然是两种东西。
还有一堆你很难在第一天想到的细节：token 计数和成本控制，长会话怎么压缩，链接断开怎么重连，用户中途打断怎么停下，每一步生成的中间产物存在哪里。
这十几个细节叠在一起，就是"能用"和"不能用"之间的鸿沟。
所有这些，都不是模型越来越好就能解决的问题。都是 harness 工程。
模型决定上限，harness 决定兑现率。
两个 IQ 完全相同的人，一个受过专业训练、有合适工具、有团队配合；另一个赤手空拳。最后能交付的工作完全不在一个量级。
AI 行业在大模型能力提升速度放缓的情况下，都发现了 agent harness 这片价值洼地，以及其跟模型之间相乘法的关系。DeepSeek 也开始组建自己的 Agent Harness 团队。
模型的能力当然会持续提升，但你的 agent 没做好。原因和模型能力无关，是 harness 那层的缺失。
三、Agent 项目的真正卡点
过去一年里，几乎每个有点规模的公司都在立项做 agent。交易 agent、营销 agent，组建产研团队，然后六个月过去，绝大多数项目都卡住了。
如果你贴近看他们工程师的日常工作，会发现一个很荒诞的事实：这些团队 80% 的时间，根本没在解决业务问题。他们在搭基础设施。
一个想做交易 agent 的团队，原本应该把时间花在策略逻辑、仓位控制、风险敞口、市场状态判断上。结果三个月里花了两个月在接行情数据、处理下单 API、记录每一次交易决策、做异常回滚、监控 agent 的系统稳定性。
一个想做营销 agent 的团队，原本应该研究用户分层、渠道转化、素材策略、campaign 节奏。结果工程师天天在处理工具调用失败、素材生成链路断掉、CRM 和广告平台权限打通、A/B 测试数据怎么回填给 agent，以及多轮对话之后 context 太长被截断的问题。
它们是纯工程问题。更准确地说，是 harness 层的工程问题。
这正是当下结构性的矛盾之处。这些团队真正的核心能力，是他们的业务理解：他们懂自己客户的工单分类，懂销售漏斗的每个环节，懂行业合规边界，懂自己业务里"什么算一次成功的对话"。这些理解，是他们多年积累下来的护城河，是别人花钱都买不到的东西。
但 agent harness 这一层，和他们的业务理解关系很弱。它是重试逻辑、并发控制、context 压缩、沙箱隔离、可观测性、安全策略。让一个 SaaS 公司的产品团队从零搭 harness，约等于让电商团队自己造数据库内核。他们也许真能造出来。但等他们造完，市场窗口已经错过了。
这种局面正在整个市场上不断重演。成千上万的业务团队在重复造同一种轮子：自己写 retry，自己接 monitoring，自己处理 OAuth，自己做 sandbox，自己调 context window，自己防 prompt injection。
这种重复劳动的总成本是天文数字，而且每个团队都很难做到生产级。他们的资源、人才和注意力本来就不该耗在这里。
业务团队的精力浪费在了基础设施上，而没有时间处理让这个 agent 解决客户问题。
所以所有企业面临的"AI 落地难"，很多时候本质并不是 AI 难，而是业务团队被迫同时做两件不该绑在一起的事：既要懂业务，又要懂基础设施。
四、Harness 平台为什么必然出现
90 年代要做一个电商网站，你可能得自己写 web server，自己实现 HTTP 协议处理，自己管数据库存储引擎，自己买机柜放服务器。今天你只需要用 AWS、Vercel 等软件云服务平台，然后把注意力放回你的电商业务逻辑。
Web 这层基础设施被沉淀成通用平台之后，应用层才真正爆发。AI agent 现在正处在"web 还没有 AWS"的阶段。
历史上每一次新计算范式诞生，都会经历类似的分化过程：早期每个团队全栈自己搞，然后基础设施层迅速沉淀成平台，应用层开始爆发。Web 是这样，移动互联网是这样。最终 Agent 也会这样。
harness 这一层必须被产品化，才能有很多 agent 业务长出来的可能。这是 CREAO 观察了大量用户行为以及和很多 B 端客户在反复沟通以及合作中得到的结论。
CREAO 5 月 25 号办了一场 agent 交易大赛。规则很简单：每个参赛者领到一个默认交易策略的 agent，然后通过对话修改它的交易策略。可以让他更激进，也可以更保守；可以加技术指标，可以改风控规则，可以让它只在某些市场条件下出手。比赛过程中会有实时的 leaderboard，看谁的 agent 收益最高。
这件事真正有意思的地方，在于它把交易 agent 的业务层和基础设施层彻底拆开了。无论参赛者是专业交易员，有量化背景的工程师，还是完全不会写代码的爱好者。如果让他们每个人从零搭一个交易 agent，他们需要操心一整套东西：怎么接行情数据，怎么调用下单 API，怎么做 backtest，怎么记录每一笔交易的决策过程，怎么监控 agent 是不是挂了。这一整套做下来，专业团队都要花几个月。
但在平台上，他们要做的事只有一件：用对话告诉 agent，他们的交易思路是什么。剩下的所有东西，CREAO 的 harness 系统已经替他们解决了。行情接入、工具调用、状态管理、可观测性、错误恢复。他们看不见，也不需要看见。他们 100% 的精力都在自己最擅长的事情上：对市场的判断，对策略的设计。
这就是 harness 平台对业务团队的真正价值，业务团队的核心能力终于不再被工程问题稀释。一个交易员的核心能力是对市场的理解以及风险管理，不是写 retry、管理上下文和记忆模块的能力。
五、未来 AI 行业的三层格局
把 LLM、harness、agent 这三层看清楚之后，再回头看整个 AI 行业，你会发现它正在分化成三种命运完全不同的公司。
第一层，模型层。 OpenAI、Anthropic、Google、DeepSeek 这一类。极其资本密集，也极其容易集中。命运由训练规模、算力供给、顶尖人才、数据和推理效率共同决定。这层最终会收敛到全球少数几家公司。
第二层，harness 平台层。 这层会成为 AI 时代的 AWS。门槛不是单点技术，而是工程深度、生态广度和客户成功能力的叠加。一个好的 harness 平台，要在隔离、可观测性、工具系统、上下文管理、安全策略、权限、部署、成本控制上同时做到生产级。任何一项掉链子，平台就建不起来。
如果我们认为 agent 作为新的软件范式，其市场规模是传统互联网市场的千倍甚至万倍，那么这一层能容纳下的团队数量至少也会是云服务平台的几十倍。这层是未来 2-3 年的 AI 行业发展重心，它们承载的是整个 agent 经济的运行流量。
第三层，agent 应用层。 这层会有成千上万家公司。每家公司未必巨大，但加起来会是 AI 经济真正的主体。这层护城河不在底层技术深度，而在对业务、客户和工作流的理解深度。harness 是它们租来的水电煤，不应该变成竞争力本身。真正的竞争力，是多年深耕某个行业、某个场景、某类客户之后沉淀出来的 know-how。
这三层分化里，藏着一个反直觉判断：未来几年最危险的位置，不在模型层，也不在纯应用层，而在那些既不够 infra、又不够垂直的"半吊子 agent 产品"。通用得不够通用，专业得不够专业。这种位置会被两头挤压，很快被市场出清。
对应到具体的人，三层格局也意味着三种不同选择。
如果你在做模型，祝你好运。这条路只属于极少数玩家。
如果你在做 harness 平台，就把工程深度做到让客户感受不到你的存在。客户夸你"好用"是一回事，客户根本想不起来你存在过，只记得自己的业务跑起来了，才是 harness 平台的终极形态。
如果你在做 agent 应用，赶紧停止自己造 harness。把这一层交给专业平台，把 100% 的精力投回你最懂的那个业务。你的客户不会因为你"自研了 agent 框架"而多付一分钱。他们只会因为你比别人更懂他们的业务而留下来。
如果你是业务负责人，正在评估 agent 项目，先问一个问题：我们团队真正擅长什么？如果答案是"懂客户、懂业务、懂场景"，那 harness 这一层就别让自己的研发团队从零手搓。让一个懂业务的团队去搭 harness，最后很可能既没成为 infra 专家，也丢掉了原本的业务深度。