在Agent时代，我们看见了大语言模型能够自主思考、调用工具、紧接着开启下一轮思考，最终输出答案。在2026年的今天，随着codex、claude code、cursor的广泛使用，我们早已习惯了这样的工作方式：输入一个问题，等上几分钟到几十分钟，然后收到一串回复，以及AI修改文件、创建代码之后的结果。
随着用户问题的难度不断加大，让一个智能体从0开始构建一个完整的系统、软件、网站乃至场景，已经成为越来越多人的日常选择。甚至在评测大语言模型时，评测者也常常让模型在固定的harness下完成一次完整的系统搭建，或者生成一个可视化的复杂3D场景。尤其是在fable5模型出现之后，把快速扩张的使用场景、把动辄数小时的长任务放心地交给一个智能体，似乎有着无限的可能。从只能复现一个已有的程序（比如计算器、扫雷），到基本实现一个完整的《我的世界》，Agent展现了前所未有的长程任务实力——在一次任务中正确使用数千次工具，这样的能力在几年前是无法想象的。
但问题也恰好出现在这里：长程任务下的语义偏离。举个很简单的例子：我希望AI为我开发一款弹珠游戏。我不是提示词工程师，也没法精准地说出我要的是什么，我只知道我想要一个"可以上手游玩的游戏"。AI确实做出来了，但做出来的样子似乎不是我喜欢的——我希望的是安卓可玩的、竖屏的、霓虹色系的、赛博朋克风格UI的、画面简洁有棱角的、物理比现实重力略轻一些的、支持陀螺仪的；而AI交上来的却是web端的、横屏的、蓝紫渐变的、大圆角tailwind css的、模拟假物理的……理想很丰满，现实很骨感。对于绝大多数没有研究过提示词工程的普通人来说，想要清楚地表达一个复杂的想法几乎是不可能的——想让成品和想象中的一致，就得像写小说一样写提示词，这怎么想都不现实。可要表达的东西越复杂，提示词就越长；提示词一旦跟不上，AI就会偏离我们的想法、自行发挥，最终做出一个和我们脑海中完全不同的东西。
请注意，这里的问题已经不再是"AI够不够聪明"了。那款弹珠游戏的每一行代码可能都写得很好，物理引擎跑得也很流畅——它错的不是"做"，而是"懂"。人和AI之间隔着一条带宽极窄的通道，我们的想法在传过去的那一刻，就已经残缺不全了。 理解这一点，是理解后文所有方案的前提。
在这里特别提到一种技术：提示词优化。字面意思是在我们输入简短提示词的时候，自动生成长提示词，最终的效果也会更精细一些。对于不懂大语言模型技术的人来说，这很唬人；但想一想它的原理就会发现，这个技术更像是放风筝的时候嫌线碍事、干脆剪断它——我们的思考更少了，表达自己想法的语句更少了，让AI自由发挥去生成所谓的提示词，还不如直接让大模型自己想，毕竟后者还能为你省点token费用。
回到正题。提示词越来越长，但终究没办法覆盖到方方面面。这就像放飞了一架无法控制的飞行器：起飞前我们拼命往它的说明书里塞满注意事项，可一旦离地，它飞向哪里就全凭运气了。可以看下面这张图：横轴是任务推进的时间，纵轴是AI的理解与我们真实想法之间的偏差，图中实线为不加任何干预的情况——任务越长，偏差越大，就像飞行器随风越飘越远。
这时便出现了Plan mode（计划模式）：在任务开始之前先给出一份详细的计划和步骤，再按照步骤一步一步地完成。对应到图中就是虚线的走势——每经过一个关键节点，偏差就被拉回一次，让思路重回正轨。这在一定程度上确实能纠正AI在长任务中的思路和行为。
但问题在于，Plan mode纠正的只是"执行过程"，而不是"理解本身"——计划写得再详细，写的也仍然是"我们以为自己想要的"；计划里的每一步，都在忠实地执行一个从一开始就偏了的理解。无论是更长的提示词、提示词优化还是Plan mode，这些方案都没办法让最终的成果与用户心里的想法一致。因为它们共享着同一个前提：赌一条单线程的路线能够一击命中。而对于人类的模糊表达来说，这是完全不可能的。
因此，今天，我们提出了一个新技术：Strive，竭尽全力。它不再赌一次命中，而是反其道而行之——让大模型尽全力想象出全部的可能性，完成全部可能的工作，以多线程并发的方式，把每一条可能的路都认真走一遍。既然我们无法保证哪一种理解才是用户想要的，那就把它们都做出来：最终，总有一个，会满足用户的想法。
Strive这个词，直译过来是"竭尽全力"。它代表的是思路上的根本转变：过去所有的方案，无论是更长的提示词、提示词优化还是Plan mode，骨子里都假设存在一条"正确"的路径，只要表达得足够清楚、规划得足够细致，AI就能一击命中。而Strive承认了一个残酷的事实：用户的想法是无法被完整传输的。既然一次命中不可能，那就不要赌一次命中——用尽全力，把所有可能的路都走一遍。
如果说Agent解决的是"AI能不能动手做事"的问题，Plan解决的是"AI做的过程对不对"的问题，那么Strive要解决的是最后一个、也是最根本的问题：做出来的东西，到底是不是用户想要的。
具体来看，Strive的工作流程可以分为四个阶段。
第一阶段：意图展开（Intent Expansion）
当用户输入一句"帮我做一个弹珠游戏"时，系统不会急着把这句话润色成一段更长的提示词，而是先做一件相反的事：分析这句话里有哪些地方是"没说清楚"的。我们把这些地方称为决策点（decision point）。平台是安卓还是网页？竖屏还是横屏？霓虹赛博朋克还是像素复古？真实物理还是街机手感？陀螺仪还是纯触屏？每一个决策点，都对应着一个普通用户"懒得说、说不清、甚至自己都没意识到该说"的分歧。请注意这和提示词优化的本质区别：提示词优化是把模糊的需求压缩成一个看起来更专业的单一方向，说到底仍然是一次猜测；而意图展开是把模糊性本身当作一等公民，坦然承认"我不知道用户要什么"，然后把所有的"什么"都摆上桌面。最终产出的不是一段提示词，而是一张意图矩阵（intent matrix）——几组关键维度、每个维度下若干代表性选项，组合出几十条通往不同终点的路线。
第二阶段：并发执行（Concurrent Execution）
系统为意图矩阵中的每条路线启动一个独立的Agent实例，每个实例拥有隔离的沙盒环境——可以理解为给每个Agent分配一间互不打扰的独立工作室：各自的文件系统、各自的依赖、各自的进度，彼此看不见对方，也就不会互相踩脚。每个线程里跑的都是完整的"思考—调用工具—再思考"循环，和单线程Agent没有任何区别。这里有一个关键的省算力设计：共享主干，分叉枝叶。就像代码管理工具Git里的分支——所有弹珠游戏都需要的基础物理引擎、主循环、渲染框架只需要构建一次，各个分支从决策点开始各自生长，而不是每个线程都从零造一遍轮子。这种"几十个Agent同时开工"的图景之所以在今天变得现实，靠的正是这两年推理成本的持续下降和Agent基础设施的成熟。Strive是一个生在正确时代的方案，放在三年前，它的账单没有任何团队付得起。
值得一提的是，Strive这个名字还有一层含义：它描述的是系统的"态度"而非"结构"。Agent是一种架构，Plan是一种流程，而Strive是一种承诺——承诺不替用户做主，承诺把选择权交还给用户。
第三阶段：动态收敛（Dynamic Convergence）
如果认为Strive就是"闷头把几十个版本全部做完再让用户挑"，那既低估了它，也高估了用户的耐心。Strive真正的杀手锏在于：它把一次性的表达问题，改造成了多轮的选择问题。一个广为人知的现象是：人类很难凭空描述自己想要什么，但极其擅长在看到选项的一瞬间认出自己想要什么——让你在纸上写出"理想中的餐厅"，你可能半天憋不出一个字；但递给你一本菜单，你三秒钟就能指出想吃的那道菜。Strive利用的正是这种"识别远易于生成"的不对称性。在几十个分支推进的过程中，系统持续向用户展示各分支的关键快照，而用户的每一次操作都价值连城：说"这条路不对"，整条支线连同它身后的算力消耗立刻被剪枝（pruning）；说"这个接近了，但物理手感再轻一点"，系统就以当前分支为父节点裂变出一批新的子分支；说"把3号的UI和7号的物理结合一下"，两个分支的成果被合并进新的线程。原本要求用户在开头一口气写完的"需求小说"，被拆解成了几十次只需要动动手指的选择题——而每一次点击注入系统的信息，都是用户最初无论写多长的提示词都写不出来的。
第四阶段：结果聚合（Result Aggregation）
当幸存的分支陆续抵达终点，系统不会把一堆"版本1、版本2、版本3"甩给用户，而是让每个结果"自我介绍"：这是"安卓竖屏霓虹赛博朋克版"，那是"网页横屏极简手绘版"，每个版本都清楚标注自己在各个决策点上做了什么选择，附上截图或演示。用户面对的不再是开盲盒，而是一面挂满成品的展示墙。
当然，一定会有人问：这样做的开销是单线程Agent的几十倍，值得吗？不妨算一笔账。
先看当下。一方面，算力在降价，而人的时间和耐心没有。让一个Agent朝着错误的方向跑两个小时再推翻重来，来回几次的消耗并不比一次并发便宜，还白白搭上了用户最珍贵的东西——对工具的信任。另一方面，共享主干加动态剪枝意味着实际开销远小于理论上限：大部分分支根本活不到烧完预算的那一刻，就会在中途被用户亲手剪掉。毕竟，和让人类用户加班重写需求文档相比，GPU加班的时薪要便宜得多。
更重要的是看趋势。这几年我们正亲眼见证一件事：模型在以肉眼可见的速度"变小"。通过蒸馏、量化等技术——可以简单理解为把大模型的能力"浓缩"进更小的体积——几年前还需要一整排服务器才能跑起来的能力，如今已经能在家用电脑上流畅运行；手机和电脑开始标配AI专用芯片，开源模型与顶级闭源模型的差距也在以月为单位缩短。这一切指向同一个结论：本地部署的门槛正在快速消失，用不了多久，每个人自己的电脑、甚至自己的手机，就能同时供养一支Agent小队。
而一旦模型跑在本地，整个成本逻辑就彻底变了：没有了按token计费的账单，几十个Agent并发跑上一整天的代价，就只剩下电费。到那个时候，"让AI做几十次白工"在经济学上就不再是浪费——没有人会觉得洗衣机多转了十分钟是浪费，因为那几分钱电费不值得心疼；同样地，让五十个Agent为你出发、其中四十八个白跑一趟，代价可能还不如出门时忘记关一盏灯。这有点像九十年代的国际长途电话：按分钟计费，所以人人都长话短说；而今天的视频通话想挂多久挂多久，因为边际成本早已趋近于零。Strive等来的，正是属于它的"视频通话时代"。甚至可以说，Strive是为那个"算力即电费"的时代提前准备的方案：它烧掉的是越来越便宜的电，省下的却是永远无法再生的东西——你的时间，和你表达想法的耐心。
熟悉这个领域的读者可能会联想到一些已有技术，这里有必要划清界限。Best-of-N采样是让模型对同一个问题多回答几次再择优，但它采样的是"回答"；思维树（Tree of Thoughts）是在推理的中间步骤上做分叉搜索，但它搜索的是"思路"。而Strive把采样和搜索抬升到了一个前所未有的层级：它采样的是"问题"本身，是对用户意图的每一种合理诠释。过去的技术假设问题是确定的、只需要找到答案；Strive假设连问题都是不确定的，于是把每一种可能的"问题"都认真回答一遍。至于多智能体系统，过去强调的是多个Agent分工协作完成同一个目标，而在Strive中，多个Agent之间是同台竞技的关系——它们用各自的诠释，去竞争用户的认可。
当然，我们也必须诚实地指出Strive面临的挑战。其一是维度爆炸：如果意图展开识别出20个决策点、每个点有3个选项，理论上的组合数是天文数字，全排列显然不现实，系统必须在展开阶段挑出分歧最大、影响最重的少数维度——这又不可避免地把一部分判断权交还给了模型。Strive并不承诺覆盖所有可能性，它只承诺覆盖得比一次猜测多得多，多得足够多。其二是安全与管控：几十个Agent并发地读写文件、调用外部API，对隔离、限额和行为审计提出了全新的工程要求。其三是评测难题：当输出从"一个答案"变成"一面墙的选择"，传统的"做对没有"式评测将会失效，未来的指标或许会变成——用户花了多久，才找到自己想要的那一个。
回到开头那颗弹珠。这一次，当我说"帮我做一个弹珠游戏"时，得到的不再是某个AI替我做主开出来的盲盒，而是一整面墙的弹珠游戏：竖屏的、霓虹的、支持陀螺仪的、重力恰到好处的。我不需要成为提示词工程师，不需要写小说，甚至不需要在开口之前想清楚自己要什么——我只需要在AI竭尽全力铺满整张桌子之后，伸手拿走属于我的那一个。
从Agent到Plan再到Strive，这条线索的背后，其实是同一个事实在一步步逼近：人和机器之间的带宽，比我们想象中窄得多。长提示词试图把飞行器的说明书写得再厚一点，Plan试图在起飞前画好航线，而Strive干脆承认航线永远画不完——于是放飞整支机群，把整片天空的航线都飞一遍。
总有一架，会降落在你要去的地方。
本文由哈基米科技创始人王闫涵瑾撰写。
在哈基米科技，我们坚持深入企业一线，围绕真实业务场景打造智能体，同时提供 GEO 优化、出海增长智能体 Hermos、空间共生体 PONA，以及云服务器与 AI 算力服务。
如果您正为需求说不清而犯难，为品牌在大模型中被写错而困扰，为外贸线索对不上而着急，或是在服务器与算力的选择上举棋不定——都欢迎随时与我们聊聊。问题再小，也值得被认真对待。
官网：https://catswing.cn
邮箱：tj111m@foxmail.com
电话：17629730802版权所有 © 2026 平顶山市哈基米与他的朋友们科技有限公司（哈基米科技）。转载请注明出处。