为什么你的agent项目总是难以落地

绝大部分agent项目在拿到业务正反馈之前，就被耗死在了手搓agent harness这些基础设施上

很多人第一次被AI写代码震撼，都是因为Cursor或Claude Code。

你让它修一个bug、重构一个模块、加一个功能，它真的会去读相关文件、跑测试、看报错、回头改。整个过程行云流水，让你感受到AI真的开始替代初级工程师了。

然后你很快会冒出第二个念头：它底层用的不也是Claude吗？我也有Claude API。我是不是自己也可以做个agent来解决我的业务问题？

两周之后，你做出来一个磕磕绊绊的东西。它有时候会调工具，有时候卡住不动。聊几轮context管理又出了问题。

大家都有一样的模型，但是agent效果却天差地别。

接下来很多人会犯第二个错误：以为问题出在prompt没调好，RAG没做好，或者是需要加个记忆模块。于是花一个月调prompt、加向量检索、在Opus和Sonnet之间来回切。

效果比之前好了一些，但距离面向业务落地还差得远。

问题其实出在了模型和你的应用之间那一层。也就是现在在AI行业越来越频繁讨论的术语：agent harness。

这篇文章讲清楚三件事：

LLM、agent harness、agent这三者之间的关系是什么；为什么此刻有几千个业务团队正在错误的战场上慢性死亡；以及，一旦你看清楚这三层，整个AI行业未来的发展格局会变得完全不一样。

要理解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，为什么Claude Code让你觉得“AI真的可以替代初级工程师”，而你自己用API搭出来的东西让你觉得“AI还差得远”？

答案是：Claude Code赢在harness。

具体到工程细节，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，组建产研团队，然后六个月过去，绝大多数项目都卡住了。

如果你贴近看他们工程师的日常工作，会发现一个很荒诞的事实：这些团队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难，而是业务团队被迫同时做两件不该绑在一起的事：

既要懂业务，又要懂基础设施。

讲到这里，开头那个问题就变成了一个更大问题的切片。

Claude Code和其他agent团队之间的差异是有一整支团队，专门负责做harness这一件事。

而你的业务团队既要懂业务，又要从零搭harness。harness这一层本来就不该由业务团队来做。

90年代要做一个电商网站，你可能得自己写web server，自己实现HTTP协议处理，自己管数据库存储引擎，自己买机柜放服务器。

今天你只需要用AWS、Vercel等软件云服务平台，然后把注意力放回你的电商业务逻辑。

Web这层基础设施被沉淀成通用平台之后，应用层才真正爆发。

AI agent现在正处在“web还没有AWS”的阶段。

历史上每一次新计算范式诞生，都会经历类似的分化过程：早期每个团队全栈自己搞，然后基础设施层迅速沉淀成平台，应用层开始爆发。

Web是这样，移动互联网是这样。最终Agent也会这样。

我在CREAO这一年最深的体会，就是这件事：harness这一层必须被产品化，才能有很多agent业务长出来的可能。这是我们自己观察了大量的用户行为以及和很多B端客户在反复沟通以及合作中得到的结论。

举个最近的例子。

我们5月25号就要办一场agent交易大赛。规则很简单：每个参赛者领到一个默认交易策略的agent，然后通过对话修改它的交易策略。

比赛报名入口：https://community.creao.ai/campaigns/agent-trading/s1

你可以让它更激进，也可以让它更保守；可以加技术指标，可以改风控规则，可以让它只在某些市场条件下出手。比赛过程中会有实时的leaderboard，看谁的agent收益最高。

这件事真正有意思的地方，在于它把交易agent的业务层和基础设施层彻底拆开了。

无论参赛者是专业交易员，有量化背景的工程师，还是完全不会写代码的爱好者。

如果让他们每个人从零搭一个交易agent，他们需要操心一整套东西：怎么接行情数据，怎么调用下单API，怎么做backtest，怎么记录每一笔交易的决策过程，怎么监控agent是不是挂了。

这一整套做下来，专业团队都要花几个月。

但在我们的平台上，他们要做的事只有一件：

用对话告诉agent，他们的交易思路是什么。

剩下的所有东西，CREAO的harness系统已经替他们解决了。行情接入、工具调用、状态管理、可观测性、错误恢复。他们看不见，也不需要看见。

他们100%的精力都在自己最擅长的事情上：对市场的判断，对策略的设计。

这就是harness平台对业务团队的真正价值，业务团队的核心能力终于不再被工程问题稀释。

一个交易员的核心能力是对市场的理解以及风险管理，不是写retry、管理上下文和记忆模块的能力。

我们办这场大赛的真正目的，其实也不只是看谁的策略最强。

我们想让参赛者亲身体验一次：当你把基础设施完全交出去，只专注于业务本身时，做agent会变成什么感觉。

一旦体验过，很多人就回不去了。

这和用过AWS的人不会再想自己买机柜，是同一个道理。

把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专家，也丢掉了原本的业务深度。