prompt 的撰写技巧只是“术”的层面，不能说不重要，但是更底层的东西“道”，“道”是你的认知层级，思维方式，和看穿本质的能力。“问的问题”本身是最重要的，你问出什么问题，远比你怎么问更致命。因为提问本身就暴露了你思考的天花。

相当于武功里面的，招式 vs 内功，张无忌学的太极拳为啥招式都忘记了，打出来，还那么厉害？

举个例子：
1. “帮我写一篇中国咖啡外卖市场的调研报告。”
2.“我想写一篇关于中国咖啡外卖市场的调研报告。请帮我分析一下市场规模、主要玩家（瑞幸、星巴克、Manner）的商业模式和优劣势，并预测一下未来的发展趋势。”
3. 见图

还是竞争好，估计又放额度了， gpt-6-astra max 跑了 70 分钟的 20w 左右的大型代码仓库重构了， 消耗 2% 的额度，这感觉正常了，

隔着前两天，得二三十的额度没有了，

一个 200$ 的 Pro 账号，7 天的额度， 用量大致 8 亿的 Astra + 18 亿的 Sol + 3 亿的 Terra + 2.5 亿的 luna，折合 api 费用 约 1980$ 。

Fable 5 low 和 GPT 5.5 high 是两个极具性价比的强模型，应该作为日常编码的主力模型！

题答对了不等于真的会做，面对未知场景不一定能解答得好。所以编程领域的 benchmark，业界共识现在更倾向于 DeepSWE，它基于 GitHub 上 91 个开源仓库，每个仓库一到两道题，题目全部是原创私有的， 公开的 issue 和 pr 中看不到，

公开答案的问题在于，模型在训练过程中大概率已经见过了，所以 SWE-Bench、SWE-Bench Pro 这两个 benchmark 存在很大程度的数据污染，顶尖模型在上面已经拉不开差距了，不再可信任了。

白天又在工作场景里深度用了一天 Fable 5 ， 有种去年 10 月份 Opus4.5 发布时候的感受，

体感上 Fable 5 这应该是个非常大的模型，厚重、稳定、聪明，语言表达精准、优美、克制，聊起来非常痛快，

还特别有主见，经常坚持自己的想法，关键是有些场景你会发现它的坚持是对的，是我自己确实没想到，这种感觉在整个仓库级别的架构设计、大规模重构、跨仓库联动的时候尤其明显，非常精准，

而且速度快得离谱，比 Opus 4.8 快多了，不知道是不是在这个模型上加大了算力，今天再回头用 4.8，跟弱智一样，

贵是有道理的，有机会的话，强烈建议大家都去用一下。

Claude Fable 5 的表现令我震惊，解决了一个困扰了我很久的难题，

孩子的太空教育项目有一个宇宙尺度级别的演示环节，从银河系出发，到附近的星系、本星系团、室女座超星系团、拉尼亚凯亚超星系团，一直拉到可观测宇宙的尺度，这个东西相当庞大复杂，之前用 Opus 4.8/4.7/4.6，GPT-5.5/5.4 来回折腾了很久，反反复复，要么做出来物理参数全对但没法给小孩看，要么视觉上太假太糙，不够直观不够震撼，总之就是达不到”小孩看了会’哇’“的那个标准，只能凑活的看，凑活着理解，

但 fable 5 一次性搞定了，40 分钟，效果非常的丝滑、顺畅，视觉效果牛的一批，

当然这里面很重要的一点就是 prompt 一定要告诉他目标是什么，什么样的效果是好的

在复杂架构设计方向，Opus 4.8 还是打不过 GPT-5.5，但这次新出的 Ultra Code 模式，很值得大家去试，效果非常好。

我拿 GPT-5.5 Pro 做的架构设计，让 Opus 4.8 Max 去挑毛病，基本一个 bug 都找不出来，

但一切到 Ultra Code，它会为了“找 bug、找设计漏洞”这件事，动态拉起一个 workflow，专门编排一套多 agent 流程去干，结果完全不一样，bug 一个接一个被挖出来，还能挖好几轮，GPT-5.5 Pro 已经改了好几轮了，

单模型能力没赢，但借助工程编排能力，采用大量的算力、loop 循环对抗验证后，把 Opus 单打独斗时根本使不出来的劲，硬生生逼了出来，效果也是真的好！

Anthropic 这套操作其实很常规，业界冒出好的设计模式，它就很顺手地“抄”进来。OpenClaw 那种手机端多 channel 联动，后来成了 Claude Code channels 加 Telegram 插件，Hermes 那种动态 DAG 的多 agent 编排，这次也进了 4.8 的 dynamic workflow，也就是这个 UI 非常炫酷的 Ultra Code 模式。

这件事再一次证明，模型能力再强，真到高难度、要稳定交付的地方，最后扛事的还是工程能力，也就是现在越来越重要的 harness 工程。

对我们自己设计 Agent 也一样，不能只指望模型自由发挥，关键任务还是要拆 workflow、定角色、做反复校验、把不确定性压进工程框架里。

最终效果 = model + harness。

Opus4.8 语言混乱的问题还没解决，说话看不懂已经比 Opus4.7 强多了，但是还比不上 Opus4.6 ，

纯 coding 能力的突飞猛进，带来了语言能力的下降，看来 Anthropic 最近被逼的压力很大，为了赶时间，没能平衡好模型各个维度的性能， 乱了自己的节奏的感觉

Claude Code Agent Teams 的实现方案架构图，很形象，模拟人类的小团队的分工协作机制。

团队创建、任务分工（task list）、成员相互沟通（mailbox）、权限隔离（permittion）、质量检查（hooks） 等

未来 Agent 的组织结构，会越来越像人类的组织结构 ！

今日发现 Hermes Agent 的 Kanban 设计的很精彩，它不是简单给多个 Agent 提供一个共享文件，而是把“人类组织协作机制”抽象成了 Agent Runtime 中的底层支持，

多个 Agent 虽然上下文彼此隔离，但通过共享任务状态、交付物、评论、依赖关系和运行记录，依然能够像真实团队一样协作推进同一个目标，

这本质上非常像人类敏捷研发中的 Scrum 站会机制，产品、设计、开发、测试并不共享彼此完整上下文，但会围绕同一个任务卡片、验收目标和阻塞问题持续同步，

Hermes Kanban 做的，其实是把这套“组织协作协议”原生搬进了 Agent Teams 中，而且实现了一个非常精彩的产品闭环。

多 Agent 系统最终拼的 ，可能不是模型能力 ，而是 Agent 之间的组织协作能力 ！

这两天做 Agent 开发选型，一个很强的体感是：Agent 的主战场正在从 Python 转向 TS，

更准确地说，变化不只是语言迁移，而是这一代 Agent 的核心能力开始从“模型调用”转向“执行系统”，

过去很多 LLM 应用主要围绕 RAG、Prompt 编排、embedding、数据处理和模型服务展开，所以 Python 是天然主场，

但现在的“执行型 Agent ”要进入真实工作环境，要接 CLI、IDE、文件系统、terminal、权限审批、流式事件、插件系统、任务恢复和多轮执行，

这背后就是近期火爆的的Agent Harness，

Agent Harness 可以理解为包在模型外面的一层执行底座：它负责上下文管理、工具调用、状态保持、权限控制、任务循环、错误恢复和人类审批，把一个只会生成文本的模型，变成一个能持续推进任务的软件执行体。

这也解释了为什么 Claude Agent SDK、Codex SDK、OpenCode、Pi 这些新一代 Agent 框架越来越偏 TS，

TS 适合做类型清晰的 SDK 边界，Node 适合处理事件流、子进程、CLI、IDE 和 Web UI，npm 生态又方便快速分发插件和工具，

再叠加几家领先 AI 公司早期产品选型带来的路径依赖，文档、示例、插件、社区贡献都开始向 TS 聚集，

所以Agent 从模型应用走向任务执行系统之后，台前运行层的技术栈发生了迁移，

Python 还会继续留在模型层、RAG、数据处理和评测体系里，但执行型 Agent 的宿主层，TS 正在变成更自然的选择，

Node 这波也挺有意思，绕了一圈，居然在 Agent 时代又杀回来了，

技术没有高低，但生态有先后，

这一次，Python 可能真的要从 Agent 框架的台前，退到幕后了！