maolon

我说定型文就是好用
就很...你懂的吧

用的 zai 的 coding plan （ pro ），opus4.6-4.7 水平左右吧，其实很难评价
因为国产模型一直是跑分高（跑分一般覆盖主流语言和应用场景）但是 corner case （比如冷门一点的语言）一直不如 a/和 oai ， 数据分析能力也是差那么点水平，根据用途不同上下限差很远

你看小米就知道这个追起来难度不高了，腾讯等着你们钱砸的差不多了，市场差不多明确了再砸钱下场追也不迟，

顺带一提腾讯也不是没有自己 LLM 模型只是比较路边而已，也就是团队在，资源在，养着团队等就行了

只有 cursor+composer2.5 组合, $20 的基础套餐就基本用不完了，$60 更是夸张到每月用个 2500M ，缺点是规划和前端差一些，规划用其他模型（比如 glm5.2 ）补上就行了。当然 cursor 只要用其他家的模型他的 quota 就会瞬间消失，

可能 cursor 做 coding worker ，opencode go 的$10 的 glm 做 planning 就是非常好的组合了

本来 codex 是个很好的选择，可惜 5.5 降智到狗都不用（一半以上的请求的 thinking effort 被限制在 512 tokens ），除非 5.6 出了不然不需要考虑

这么多概念就是因现有的没法完整描述，以及有他的历史阶段性
prompt 试图解释的是如何有效的使用提示词驱动大模型，对应的是 2022-2023 最早期阶段 context 只有几 k,对话只能对个几段就必须截断的阶段，这个阶段能完整的跑个一两个 round 就不错了，所以才强调怎么在一个 round 里高效的输出结果。
context 对应的是第二阶段的 2024-2025,这个阶段里模型的上下文空间快速增长，让多轮的长任务成为可能，然后一个现象就被观察到了，就是 context rot, 上下文腐化，一个上下文里堆了太多的东西会影响 agent 表现，所以提出了 context engineering 用于解释如何合理的管理你的上下文。
harness 对应的第三阶段 2025 年末到 2026 年初，此时 agent 已经可以执行非常长的任务了，问题变成了任务漂移，此时 harness 解决的如何使用外部约束硬性约束 agent ，减少他的上下文漂移。
loop 这个我觉得才是有点没活硬整的部分，因为我认为 loop 本身就应该归入 harness 的一部分，虽然现在 agent 本质上就是一个 loop ，以及如果你学过控制原理就会发现不管是 harness 还是 loop ，最终的结构都是一个控制反馈回环。

什么文艺复兴，你大概不知道谷歌曾经有一个死了 10 年的竞争对手叫 ChaCha 吧

@catwalk #6 一般不开， 本身速度就很快了，开了是 x3 的价格，我觉得提升的速度不值这个价