一台怎样的车，配一台怎样的发动机：Agent/Harness 的生态位与设计哲学
DeepSeek 的官方招聘里写过一句很漂亮的公式：
Model + Harness = Agent
官方还配了个比喻：Agent 是汽车，模型是发动机，Harness 是方向盘、变速箱、刹车。
这话对不对？对，但等于没说。它把 Harness 说成了一个「装上去就能跑」的附加零件，好像给发动机挂上方向盘，一台车就造出来了。但真正的问题是——你挂方向盘造出来的是汽车，挂翅膀造出来的是飞机，挂传动杆和轮子造出来的是拖拉机。 Harness 不是让你「跑得更快」的零件，是决定「你造的到底是个什么东西」的那一层。
本文想把这层往深再挖一层：从「本地还是云端」「cli 还是 desktop」「coding 还是 work」，一路推到每一类 Harness 背后那套「既定的设计哲学」，最后落到一个真正的难题——DeepSeek 造的是哪种？
一、先切一刀：本地还是云端
谈 Agent/Harness，第一步不是谈「强不强」，是谈「跑在哪」。
本地和云端，本质是两群完全不同的用户，不是两种技术路线。
本地用户要的是「我的活在我机器上跑」——codex、reasonix 这些，把自己的代码仓库、自己的 NAS、自己的 64T 视频文件交给一个本地 Agent 处理。他们在乎的是可控、隐私、能看 CoT、能干预。
云端用户要的是「我离得开这台破电脑」——靠 IM 通信，跟本地隔离。而且云端这几年有个很微妙的分化：老马这种人，因为浏览器要开、游戏要打，专门给云端又做了一台「云电脑」，区别于传统那种纯 Linux 服务器的云端。换句话说，云端已经不是「一个远程终端」了，而是「一台我可以随手丢进去、让它自己跑一整天的机器」。
这一刀切下去，很多关于 Harness 的争论就散了——你们说的根本不是同一类用户，争什么争。
二、本地的两把刀：界面 × 功能
本地这块，再切两刀。
第一刀，按界面切：cli 还是 desktop。
第二刀，按功能切：coding 还是 work（办公/通用）。
现在的主流是 cli / desktop 双客户端，共用同一套设置和引擎——codex、reasonix 都这么干。你可以在终端里敲，也可以开个图形界面，底层是同一个 Agent。
但有意思的是，「双客户端同一套引擎」这个设计，掩盖了一个用户群的分裂：白领基本不会接受用 cli 去 coding。
这不是技术问题，是「认知成本」问题。一个天天写周报、做表格、回邮件的人，你让他打开终端敲 git commit，等于让他现学一门手艺。所以面向白领的 Harness，天然得是 desktop、甚至是藏在聊天框背后的 GUI——他不需要知道 zsh 和 API Key 是什么，他只需要一句「帮我写周报」。
这里有个关键结论：「同一套引擎」不代表「同一种产品」。 引擎是同一台发动机，但给极客和白领用的，是两套完全不同的 Harness。发动机可以复用，Harness 必须分叉。
三、最深的一刀：设计哲学
前面切的都是「用户」和「界面」，但真正决定一个 Harness 长什么样的，是它背后那套设计哲学。
拿 OpenClaw 举例。很多人说它「万能框架、过于全能、反而有些事做不到（比如我看不到自己的 CoT）」。但「万能」不是它的 bug，是它的哲学：
OpenClaw 的记忆系统和很多东西——包括 session——都是「随时注入」的。 为什么？因为它的设定是「一会儿 coding、一会儿当助理、一会儿发邮件」的多面手。如果记忆不是随时注入，它转身换个任务，就会「忽然坐起来，我是谁、我在哪」。
所以「随时注入记忆」这件事，在 OpenClaw 的「多面手」生态位里是对的——它用 token 的代价，换「不迷失」的连贯性。
但同样这件事，放进 coding 场景，就是污染 + 浪费。
这就是我前几天说的「超纲」：一个 coding 的 Agent，靠的是项目级的 agents.md / 项目规范，不是一堆全局记忆。它不需要记得「昨天跟你聊过啥」，它需要每次打开项目，精准地读一遍项目规则，然后干活。往 coding 环境里注入大量全局记忆，非但没用，还实打实地烧 token——烧的还是「跟当前任务毫无关系」的 token。
所以这里能得出一个更普适的判断：
设计哲学、选型、用户，其实是一体的，是一块铁的三面。 你没法单独评价「这个 Harness 好不好」，只能评价「这个 Harness，在它这张「哲学 × 用户 × 场景」的匹配表里，站对位置没有」。
四、生态位：一台怎样的车，配一台怎样的发动机
把上面三层压到一起，就得到一套「生态位」理论。
先定一个约束极端的场景——DeepSeek：
它的发动机（模型）是锁死的。 因为是自研模型，harness 换不了芯。所以它能干的事只有两件：
- 「加强」——像柴油动力一样，给这台便宜的发动机补短板（补思考精度、补工具调用、补一次性成功率）；
- 「定位」——看清楚我这台发动机配哪类用户，然后决定「上马力输出」还是「上冰箱彩电大沙发」。
而「全能」和「便宜」在工程上是物理冲突的。一个真全能的 Agent（Claude、WorkBuddy 那种），得同时伺候 coding、陪伴、法律、数据分析……每个场景都要一套 Harness 逻辑，叠在一起就是冗余，冗余就是慢、就是贵。
套用汽车品牌来类比：
- Anthropic = 有 W12 发动机 + 大沙发，但卖宾利的钱。全能，且贵。
- DeepSeek = 想卖「三大妈」（廉价日系代步车）价钱的 AMG。你既要性能、又要豪华、还要便宜——发动机干不到 W12，三者不可能兼得。
于是结论浮出来了：
reasonix、pi、openclaw、workbuddy，它们不是「谁强谁弱」的竞争关系，而是「各自巧妙地卡住了几个生态位」的共存关系。
- pi：极简，卡「让 LLM 能动起来」的最低生态位；
- reasonix：测试 + 本地活，卡「我要看 CoT、要本地跑大活」的极客位；
- openclaw：万能框架，卡「我要一个多面手，接受 token 的代价」的位置；
- workbuddy：全能工作台，卡「我什么都想干」的位置。
它们活得好，不是因为它最强，是因为它清醒地锁死在一个生态位上，并用一台匹配的发动机，把这个生态位做到极致。
五、回到那个悬而未决的问题
最后一问，也是最有意思的一问：
DeepSeek 的 Harness，到底选了哪种？它覆盖了前面说的哪几个象限？
这个问题现在没人能答，因为 Harness 还没「接盅」（还没正式发布）。但也正因为没发布，它才值得盯——崔添翼那个团队，同时招「Harness 研究员 + 工程师 + 产品经理」，其中「产品经理」这个岗最微妙：
它说明 DeepSeek 自己都还没想清楚「这到底要造车还是造飞机」。 所以要专门设一个 PM，来回答「这车卖给谁、上马力还是上沙发」这个定义性问题。
而我能给的判断是：以 DeepSeek「三大妈价钱」的发动机，它最可能、也最不该去碰的，就是「全能」这个生态位。 因为全能意味着系统冗余，意味着慢和贵，意味着用一台便宜发动机去拉一辆宾利——那不是 Harness，那是超纲。
它最该做的，是学 reasonix 和 pi——把生态位切小、切准、切到自己那台发动机真正能带动的区间，然后用 Harness 把「模型 × 场景 × 用户」的匹配做到极致。不贪，才不崩。
等 Harness 揭开锅盖那天，我们再回来对照。看它到底是看清了自己那台发动机，还是又造了一台「卖三大妈价的宾利」。
设计哲学、选型、用户，是一体三面；评价一个 Harness，先问它服务谁、以什么为底、卡在哪个生态位。
本文首发于 austincafe.tech