正向编程，AI 生成的方案你都过一遍，不是自己熟悉或者预期的技术选型，就都否决让他去改。或者你给个建议。

btw：其实目前 Agent 的模式很类似团队管理。要用管理的思维去驱动 Agent 。

如果想完全一致，混合应用是最方便的。顺带还解决了热更的问题。代价就是小程序这侧不太支持（ API 缺失严重）

如果想体验最好，各自平台一份原生是最理想方案，你维护一份功能定义和产品设计文档，然后各自实现。

跨平台语言框架在现今来看，性价比不高。
1 、各自平台还是要各自匹配特性。只有逻辑和 UI 代码可以共用。
2 、性能不强。
3 、如果考虑跨到小程序，好像只有 uniapp 能符合吧？

要用第三方供应商吗？如果要用，唯一的选择就是 vscode 插件了。但是 vscode 插件有 bug ，有时候会变得特别慢，且上下文暴涨。

claude code 对于第三方供应商的要求就是 API 要支持 Anthropic 格式。

所以要看你的中转站是否支持对应格式的接口。

qwen 最厉害的是开源小模型，
qwen3.6-27B 的 Agent 能力不输 deepseek-v4-flash
qwen3.6-35B-A3B ，用 3B 的运行参数，就能实现二线模型的能力

那你这个“据我了解”有点过于片面了。

举个不太恰当的例子，你记得回家的路吗？那我问你，到你家路上的最后一个十字路口的斑马线有几条白线？

同理，对于 Coding 这个场景而言，模型不需要对于你的项目“全知全能”，就可以做到改代码。他只要知道代码在哪，以及如何搜索需要的内容即可。

“上下文太短，以至于无法装载整个项目，导致没办法产出合理的程序设计，LLM 对于 Coding 还只能是输出代码块”，这是 24 年中旬的论调。

脱离楼主本身来讲。

目前缺的就是工具，而不是模型。头部的模型 Agent 能力已经基本过线了，只要提供合理的工具和技能，模型都能正确的调度和梳理。

模型能力能替代生成和统计，但无法替代“眼睛和手脚”。拿不到上下文，LLM 即便是神仙也没办法。
所以方案 B 一定是未来的方向。


但是，在 LLM 时代，抓包工具“凭什么”必须用楼主的呢？这才是最大的问题。

我观察到的趋势，LLM 的工具越来越封闭化。大模型公司逐渐的会把自己的工具生态封闭起来，因为 LLM 本身无状态，不会有迁移成本。所以通过闭源工具自身构成上下文壁垒，形成所谓的“数据飞轮”，才是 LLM 服务的核心壁垒。

之前 LLM 公司不重视工具，是因为模型公司之前基本上是再打融资战，要的是投资人能看到效果和感动世界。
现在则是实际的刺刀见红。在争夺实际的 C 端客户。

最近正在做这方面的测试，目测在链接 deepseek-v4-flash-high 时候，Claude Code 的单次成功率会高一点点。

但是，Deepseek 官方明确说明：“思考模式下，对普通请求，默认 effort 为 high ；对一些复杂 Agent 类请求（如 Claude Code 、OpenCode ），effort 自动设置为 max”。

所以这个就很难控制变量。目前也只是个人体感。

要是我是 Claude Code 的产品，我会更诛心一点，
一个复杂任务跑完，我会帮你偷偷免费跑一版 Opus 的版本。并以你的第三方 provider 的结果作为比较对象，如果质量吊打，就附带一个订阅二维码，把 Opus 的结果展示给你。告诉你 20$订阅后，自动就会把 Opus 修改的版本 diff 到代码库。

闭源工具就是这点不好，更新之后故意负优化或者烧你 token 你完全没法求证或反制。

要看甲方要求。

总体而言：
国产化对于硬件的要求高于软件。
对于服务器的要求高于客户端。
对于公共服务（中间件、数据库）的要求高于业务服务。

目前用的是 Claude Code 多一些，同样的问题，TRAE 的成功率不如 Claude Code
但是 TRAE 对于改动的管理要好一些。Claude Code 的 VSCode 插件不像 Copilot 、TRAE 那么友善。有点像只是 CLI 的 UI 化。

因为工作内容从之前的逻辑因果系统切换到了混沌概率系统。
类似于从开发岗转到了管理岗+开发岗。

人肉上下文更多了，占用了更多的大脑缓存。

之前你只需要思考你自己的 function 如何实现即可。
现在你需要思考：

到底如何才能生产出这个 function ？
这个 function 的生产任务更适合交给谁？
我怎么证明这个“人”生产的 function 是合格的？
我靠他这个 function 的实现我怎么看不懂？
他这个 function 的实现真的符合我的要求吗？
这个“人”生产这个 function 怎么耗费了我这么多额度？怎么提升费效比？
我要不要把这个“人”的经验提炼成 skill ？
这“人”写的能过 code review 吗？我要不要微调一下？
算了就这样吧。

大概是这样，和我 10 年前带组的感觉差不多。

1 、各家后训练的算法技巧提升了。导致最终输出更加贴合用户的需求。
2 、AI 工具的能力逐渐丰满，让 LLM 不再是两眼一抹黑。

当初有这个问题有很多个维度的理解。
1 、为了占领市场（凸显效果好），各家都会有意的让模型随机性加大。
2 、各家的工具都太粗糙，一开始连联网能力都没有。普通人根本没有能力提供给 LLM 合理的上下文。就像是你的女朋友跟你说“我的那个在哪里”，你怎么答都是错的。
3 、模型预训练没形成范式，全靠大力出奇迹，没有基础认知这个概念。

@EthanZC 看似包月，本质上还是按量付费。只是按量付费的套餐。
这其中和 API 之间的费用差距主要在于赌你用不完，或者因为有有效期而导致你无法合理最大化产出。

这其中最值得玩味的还是 Copilot ，从完全的按照请求次数收费，一口气转型成 39 美元套餐=39 美元 token 额度≈各家 API 价格。这其中的脑回路也是神中之神。颇有点包子 2 块钱一个，10 块钱 5 个的神韵。

@letwewell 盈利没有问题，但是历史上从来没有出现过这种消费者完全没有任何信息的商业模式。
类似于，你去一个饭馆吃饭，你只能说你饿了。然后你吃什么、吃多少、花多少钱，都是饭馆说了算。

即便是这样，其中一家饭馆还要跳出来说他家的饭馆必须领先行业，否则全世界的人都要饿死。
只能说魔幻……

模型提供商自从开始转型成“token 收费”，就没有动机去优化费效比了。

而且你这次请求跑了多少 token ，其实也是他们说了算。
有的提供商甚至会弄类似“代币”的虚拟概念。他说你花了多少，就是多少，无需解释。

@hutng 是的，如果是 llama.cpp 可以用 llamabench 来验证下。pp 是输入速度，tg 是输出速度。

Agent 执行一次任务要无数次交互 LLM(查网址、跑终端、改代码)，每次都要罚站。和 chat 场景完全不同。

@hutng 用的是什么硬件？使用 Agent 工具调用本地 LLM 的时候，首次启动的输入 token 少则 5~6K ，多则 10k 起步。prefill 速度比 decode 速度还要重要。5090 的 prefill 速度大概是 3000+t/s 。

如果设备的 prefill 速度不过千，那就相当于每次调用 LLM 都要罚站。