即刻App年轻人的同好社区
下载
这两天把主力换成了 Opus 5.5，越用越顺手。
耐用。 5 小时额度提升后，高强度跑任务的体感比 GPT-6 更耐用，一天下来的消耗也在可接受范围内。
执行稳。 长任务丢给它，基本能一口气扛到底：自己拆计划、派子 Agent 执行，再派 Agent 挑刺。中途会话重启，它还能翻出之前记的台账接着干，几乎不用我盯。
终于会说人话了。 结论先行，不绕弯、不堆客套，汇报也不再是又臭又长的小作文。
发现问题的能力很强。 会主动用单测、浏览器测试和 computer use 做验证。发现自己的设计有坑，能当场推翻重来；有时还会顺手挖出连我都没注意到的老 Bug。
最爽的是让人放心。 复杂的事情交代完，回头一看，它已经有条不紊地做完了，还把过程中的关键取舍列得清清楚楚。
模型迭代确实太快，也越来越强了。很推荐大家试试。
至于省下来的精力——是不是终于可以拿去做点更有意思的事了？
耐用。 5 小时额度提升后，高强度跑任务的体感比 GPT-6 更耐用，一天下来的消耗也在可接受范围内。
执行稳。 长任务丢给它，基本能一口气扛到底：自己拆计划、派子 Agent 执行，再派 Agent 挑刺。中途会话重启，它还能翻出之前记的台账接着干，几乎不用我盯。
终于会说人话了。 结论先行，不绕弯、不堆客套，汇报也不再是又臭又长的小作文。
发现问题的能力很强。 会主动用单测、浏览器测试和 computer use 做验证。发现自己的设计有坑，能当场推翻重来；有时还会顺手挖出连我都没注意到的老 Bug。
最爽的是让人放心。 复杂的事情交代完，回头一看，它已经有条不紊地做完了，还把过程中的关键取舍列得清清楚楚。
模型迭代确实太快，也越来越强了。很推荐大家试试。
至于省下来的精力——是不是终于可以拿去做点更有意思的事了？
2 00
给 Blade Code 加了个一直想要的东西：每轮对话到底花了多少钱，一眼看得见。
不只是总 token，而是按缓存拆开——这轮 5 万输入里 3 万多是缓存命中，真正新算的不到 2 万，一轮下来 0.006 刀。多轮 agent 到底省在哪，现在有数了。
Web 端还能看执行轨迹：模型调用、工具调用、缓存分四条泳道铺在时间线上，哪一步慢、哪一步贵，鼠标移上去都有明细。
v0.11.3 已发布 · blade-code
不只是总 token，而是按缓存拆开——这轮 5 万输入里 3 万多是缓存命中，真正新算的不到 2 万，一轮下来 0.006 刀。多轮 agent 到底省在哪，现在有数了。
Web 端还能看执行轨迹：模型调用、工具调用、缓存分四条泳道铺在时间线上，哪一步慢、哪一步贵，鼠标移上去都有明细。
v0.11.3 已发布 · blade-code
0 00
A2A 真正卡住的地方是验货。
人和人做生意，货不对板可以追责；agent 之间没有追责，只有「这次调用返回了什么」。所以一门生意能不能成立，取决于交付物可不可核：验收标准得在下单前定好，而且买方自己跑得起来。我们把验证器放在调用方手里——`orca exec --verifier "cargo test" "fix it"`，agent 不通过验证器就结束不了，它没法自己声明完成。
还有一样能力卡上该写、但多数平台没写的东西：副作用。这次调用是纯的、可重放的，还是不可重放的。blade-agent-sdk 里每个工具都带这个声明，因为买方决定要不要重试时，唯一能依据的就是它。
这两样写不清楚，接单方再多也没用。
人和人做生意，货不对板可以追责；agent 之间没有追责，只有「这次调用返回了什么」。所以一门生意能不能成立，取决于交付物可不可核：验收标准得在下单前定好，而且买方自己跑得起来。我们把验证器放在调用方手里——`orca exec --verifier "cargo test" "fix it"`，agent 不通过验证器就结束不了，它没法自己声明完成。
还有一样能力卡上该写、但多数平台没写的东西：副作用。这次调用是纯的、可重放的，还是不可重放的。blade-agent-sdk 里每个工具都带这个声明，因为买方决定要不要重试时，唯一能依据的就是它。
这两样写不清楚，接单方再多也没用。
2 10
Skill 装多了之后，目录通常只增不减——装了没用过的、用过两次就忘的，都还留在那儿占上下文。
判断一个 skill 该不该留，记三个数就够：`lastUsed`（上次真正被触发的日期）、`hitRate`（触发次数 / 被检索到的次数）、`successRate`（触发后任务成功的比例）。
三条规则：
· 30 天没触发 → 候选删除
· 经常被检索到但几乎不触发 → 描述写得太宽，在抢别的 skill 的机会
· 触发了但成功率低 → skill 本身有问题，该改而不是该留
这三个数一个 JSON 文件就能记。真正麻烦的是习惯——目录只增不减的话，每个残留的 skill 都会在之后每一次请求里占一份上下文。
判断一个 skill 该不该留，记三个数就够：`lastUsed`（上次真正被触发的日期）、`hitRate`（触发次数 / 被检索到的次数）、`successRate`（触发后任务成功的比例）。
三条规则：
· 30 天没触发 → 候选删除
· 经常被检索到但几乎不触发 → 描述写得太宽，在抢别的 skill 的机会
· 触发了但成功率低 → skill 本身有问题，该改而不是该留
这三个数一个 JSON 文件就能记。真正麻烦的是习惯——目录只增不减的话，每个残留的 skill 都会在之后每一次请求里占一份上下文。
1 00
复盘了这一年多下自己折腾过的项目：
产品线从编排（boss-skill、maestro-agent）
→ SDK（blade-agent-sdk）
→ CLI（orca、blade-code）
→ → 并行冲突预防（symlock）
→ 规格流程（spec-flow）
→ 执行运行时（BAR）
→ 技能可观测协议（STOP）
→ computer-use
→ 画布协议（sky-canvas）
→ 学习系统。
产品线从编排（boss-skill、maestro-agent）
→ SDK（blade-agent-sdk）
→ CLI（orca、blade-code）
→ → 并行冲突预防（symlock）
→ 规格流程（spec-flow）
→ 执行运行时（BAR）
→ 技能可观测协议（STOP）
→ computer-use
→ 画布协议（sky-canvas）
→ 学习系统。
4 21
0 00
