Pinned Tweet
Want to try Muse? Here's my invite code: VBBM4X
Join Muse, then enter it in Settings > Redeem token within your first 48 hours. First come, first served — when it's gone, it's gone.
@ihm185 @iskakovdev @ansel8791 — passing it on in case it's useful. #AIAgents #AITools
Join Muse, then enter it in Settings > Redeem token within your first 48 hours. First come, first served — when it's gone, it's gone.
@ihm185 @iskakovdev @ansel8791 — passing it on in case it's useful. #AIAgents #AITools
5
1
4
541
上线 agent 前，我会先写一张失败清单：工具超时怎么办、部分成功怎么办、外部已经生效又怎么办，每种情况对应的人工接管动作写清楚再扩量。很多上线后的慌乱，不是模型不够聪明，而是失败路径没有事先命名，出了问题只能现想。
2
0
1
16
做深度调研时，我现在的做法是先把问题拆开，让 Muse 自己去查资料、对照几个不同出处，再汇总成一份带来源的笔记给我过目——省掉自己逐个翻页比对的时间，结论从哪来的一眼能看到。
— 我在用 Muse 跑这类活，邀请码 VBBM4X，注册 48 小时内在设置里 Redeem token 填码，你我都有 token。
— 我在用 Muse 跑这类活，邀请码 VBBM4X，注册 48 小时内在设置里 Redeem token 填码，你我都有 token。
0
0
0
61
生产 agent 最容易被低估的一环，是事后能不能复核。不是只看它最后答得对不对，而是每一步能不能回放：当时收到什么输入、调了哪个工具、凭什么做了这个决定。日志如果只记结果，出问题就只能猜；把过程留成可查的收据，复盘才有抓手，改动也才敢下手。
0
0
0
33
我让 Claude 只做规划和验收、写代码交给便宜的执行模型，跑了两周，数据比预想的好。
痛点很具体：全程用强模型，配额烧得快；全用便宜模型，质量又不稳。所以我做了 openswarm，一个配额感知的多 agent 调度器：
- Claude 拆任务、做规划、最后验收
- 每个任务按实时配额和能力，路由给 Codex / OpenCode Go / DeepSeek 里最便宜且够格的一个
- 每个任务关在独立的 git worktree 里跑，有硬预算封顶，跑不完就停，不会无限烧
实测数据（SWE-bench Verified 里 6 道硬题，sympy / pytest / pylint，官方测试判定）：
- openswarm（Claude 规划 + 便宜模型执行）：6 题解出 5 题，中位成本 $0.0377 / 题
- 单 agent 基线：解出 3 题
- 配额路由模拟（80 个任务 × 7 种配额场景）：openswarm 第一次尝试就撞上已耗尽配额的比例是 0%，单 Codex 基线是 28.6%
先把丑话说前面：样本很小，n=1，这几个数字只能算方向性证据。完整的跑法、原始记录和翻车的部分都摊在仓库里，自己判断。
github.com/surlymochan/op…
另一条线是 openflow：把交付流程本身管起来，YAML 定义阶段、红绿 TDD 证据门由代码强制检查，不靠提示词自觉。一个 xflow CLI 同时驱动 Codex、Claude Code 和 Cursor，已经发到 npm。
github.com/surlymochan/op…
在用多 agent 的朋友，任务路由这一层你们是怎么做的？靠模型自己选，还是外面有一层调度？
#AIAgents #AITools
痛点很具体：全程用强模型，配额烧得快；全用便宜模型，质量又不稳。所以我做了 openswarm，一个配额感知的多 agent 调度器：
- Claude 拆任务、做规划、最后验收
- 每个任务按实时配额和能力，路由给 Codex / OpenCode Go / DeepSeek 里最便宜且够格的一个
- 每个任务关在独立的 git worktree 里跑，有硬预算封顶，跑不完就停，不会无限烧
实测数据（SWE-bench Verified 里 6 道硬题，sympy / pytest / pylint，官方测试判定）：
- openswarm（Claude 规划 + 便宜模型执行）：6 题解出 5 题，中位成本 $0.0377 / 题
- 单 agent 基线：解出 3 题
- 配额路由模拟（80 个任务 × 7 种配额场景）：openswarm 第一次尝试就撞上已耗尽配额的比例是 0%，单 Codex 基线是 28.6%
先把丑话说前面：样本很小，n=1，这几个数字只能算方向性证据。完整的跑法、原始记录和翻车的部分都摊在仓库里，自己判断。
github.com/surlymochan/op…
另一条线是 openflow：把交付流程本身管起来，YAML 定义阶段、红绿 TDD 证据门由代码强制检查，不靠提示词自觉。一个 xflow CLI 同时驱动 Codex、Claude Code 和 Cursor，已经发到 npm。
github.com/surlymochan/op…
在用多 agent 的朋友，任务路由这一层你们是怎么做的？靠模型自己选，还是外面有一层调度？
#AIAgents #AITools
3
0
0
74
agent 的回滚边界，要画在系统外面。
代码和内部状态可以回滚，但已经发出的消息、建好的工单、捕获的支付，收不回来。
所以补偿清单要和回滚分开建：回滚管内部状态，补偿管外部影响。
每条补偿都要带幂等键，先查后做、做完留痕，避免一次失败变成两次打扰、两次扣款。
回滚成功，不等于外部影响已经收拾干净。
代码和内部状态可以回滚，但已经发出的消息、建好的工单、捕获的支付，收不回来。
所以补偿清单要和回滚分开建：回滚管内部状态，补偿管外部影响。
每条补偿都要带幂等键，先查后做、做完留痕，避免一次失败变成两次打扰、两次扣款。
回滚成功，不等于外部影响已经收拾干净。
0
0
0
19
给 agent 的失败先分档，再谈重试，顺序不能反。
分档标准只看两点：影响是否可逆、证据是否足够定位原因。
一档可自动重试：影响可逆、原因明确、重试不会放大副作用，比如短暂的网络抖动。
二档需人工确认：影响可逆但原因不明，或者重试可能重复扣费、重复写库，先停下来等确认。
三档必须停下：影响不可逆、涉及资金或外部状态已变、证据不足以证明安全，宁可中断也不要自动续跑。
很多重试逻辑的问题不是重试次数，而是把三档失败混进同一个重试通道。
分档标准只看两点：影响是否可逆、证据是否足够定位原因。
一档可自动重试：影响可逆、原因明确、重试不会放大副作用，比如短暂的网络抖动。
二档需人工确认：影响可逆但原因不明，或者重试可能重复扣费、重复写库，先停下来等确认。
三档必须停下：影响不可逆、涉及资金或外部状态已变、证据不足以证明安全，宁可中断也不要自动续跑。
很多重试逻辑的问题不是重试次数，而是把三档失败混进同一个重试通道。
0
0
1
82
多 agent 写同一份资源时，最难的不是并行本身，而是谁最后说了算。我现在更倾向先把写权限收敛到一个明确的归属：同一资源同一时间只有一个写入方，其他 agent 只提变更请求，不直接落盘。冲突先在请求层排队和合并，落盘后再对账。这样慢一点，但回滚时至少知道该找谁、该撤哪一步。你们在生产里是先锁资源，还是先合并请求？
0
0
0
43
生产里 skill 最容易翻车的地方，不是写不好，而是没人知道它存在、也不知道现在跑的是哪一版。发现靠口口相传，版本靠 latest 一把梭：某天提示词悄悄改了，agent 行为变了，却没人能说清是哪个版本、什么时候变的。我的底线很直白：skill 要有名字、版本号和适用范围，调用时能查到这三样，查不到就当它不存在。
1
0
0
58
展开一下我的做法：新版先灰度给一小部分任务，旧版保留可回滚；每次变更只写一句话说明改了什么、影响哪类任务；调用日志里记下 skill 名和版本号，出问题先按版本查，别先怀疑模型。发现层面也一样：没有统一目录，写得再好也等于不存在。
0
0
0
31
生产 agent 的人工复核队列，我现在只放三类，其他一律放行或自动回滚：
1. 对外动作：发消息、改数据、调外部系统，先审后做
2. 不可逆动作：删、覆盖、发版，没有补偿方案不放行
3. 意图不清的指令：停下来问人，别让 agent 自己猜
常见模式是：队列越长，复核越敷衍。所以规则要写进 prompt 和工具层，而不是靠人眼盯着每一步。复核不是兜底，是给 agent 划边界。
1. 对外动作：发消息、改数据、调外部系统，先审后做
2. 不可逆动作：删、覆盖、发版，没有补偿方案不放行
3. 意图不清的指令：停下来问人，别让 agent 自己猜
常见模式是：队列越长，复核越敷衍。所以规则要写进 prompt 和工具层，而不是靠人眼盯着每一步。复核不是兜底，是给 agent 划边界。
1
0
0
37
补充一点执行细节：复核人要在 30 秒内能判断三件事——原始意图是什么、这次改了什么、出问题怎么回滚。缺任何一项，我宁愿让它先停下来，也不要点通过。常见模式是复核变成走过场：只看标题就批。所以我把意图、变更摘要、回滚路径强制放在同一屏，批复只在看完这三项后才有意义。
0
0
0
15
选模型别只看榜单分数。常见做法是：先拿 20-30 个自己业务里最典型的任务做一轮对照，分数、单任务成本、失败类型一起看。
榜单第一的模型，未必是出错最少、回滚最容易的那个。生产里真正贵的不是单次调用，而是失败后的人工兜底。
我的取舍是：先定可接受的失败模式，再谈成本和速度。
榜单第一的模型，未必是出错最少、回滚最容易的那个。生产里真正贵的不是单次调用，而是失败后的人工兜底。
我的取舍是：先定可接受的失败模式，再谈成本和速度。
0
0
1
39
把 AI agent 的上下文当预算管，而不是无限续杯。常见做法是：任务描述控制在 500 字以内、单条工具结果截断到 4000 字符、单次运行工具调用不超过 50 次。
超限就停下来先向人确认，而不是让 agent 自己越翻越深。预算不是为了省 token，是为了让失败发生在可控的范围内。
超限就停下来先向人确认，而不是让 agent 自己越翻越深。预算不是为了省 token，是为了让失败发生在可控的范围内。
1
0
0
46
新工具可以加速 agent 的合并流程，但别急着把 Git 整个换掉：人看 diff、回滚、做审计还是要靠它。我的取舍是——agent 内部用版本检查解决冲突，落到主分支之前，仍然留一份人类可读的 Git 历史，否则出问题时没人能讲清楚到底改了什么。
Introducing AVP : Agent Versioning Protocol, built to replace Git for coding agents.
At Murmell, we’re building a shared workspace for teams and coding agents.
Two people, lots of agents, one monorepo.
We hit a problem: our agents were writing code faster than our workflow CI runs a day just for pull requests.
A median of 19 minutes to reach main. And 41% of staging deploys cancelled by the next merge.
Anthropic’s Scion announcement echoed what we were seeing at our own scale. So we built AVP for our own repo.
The workflow is simple: open a task → write → land.
AVP checks each change against the exact version receiving it. If another agent lands first, the changes are replayed and checked again. Conflicts go back to the agent.
With our new workflow and validation infrastructure, median open-to-main dropped from 19 to 2.9 minutes.
These are early internal results: about six hours and 31 changes, compared with the previous
3.8 days.
Git remains a compatibility bridge during the transition. The goal is to replace it.
AVP isn’t a revolution. It brings together a few ideas that have emerged as more people started working with AI agents.
It’s still early, but it’s already made our lives at Murmell a lot easier. We’re sharing it to get feedback, especially from the open-source community, and see what others make of it.
I’m curious to see how it evolves and what it could look like down the road.
Personally, I think Git - and a lot of the tools designed around how we worked in the 2000s - will eventually become obsolete as agents change how we build software.
We’ve already seen new interfaces emerge with MCP.
I think version control will go through a similar shift, and AVP is our attempt to explore what comes next.
One Rust binary. Claude Code and Codex for now. Open source under AGPL.
Blog post : murmell.com/blog/agents-ou…
GitHub : GitHub.com/mossab28/avp
We are applying for YC W27 batch, feel free to reach at mossab@murmell.com, your feedback is welcome :)
2
0
0
40
把 AI agent 放进生产后，我越来越觉得：任务拆分方式比模型选型更决定成败。
一个任务如果一次要改 3 个模块、跨 2 个系统，还要人中途拍板，agent 几乎一定会在中途丢上下文。
我的做法是：先把任务拆成“一个人 10 分钟能讲清楚”的小块，每块只给一个明确的完成标准，写完一块就停下来对齐，再开始下一块。
慢一点，但返工少很多。
一个任务如果一次要改 3 个模块、跨 2 个系统，还要人中途拍板，agent 几乎一定会在中途丢上下文。
我的做法是：先把任务拆成“一个人 10 分钟能讲清楚”的小块，每块只给一个明确的完成标准，写完一块就停下来对齐，再开始下一块。
慢一点，但返工少很多。
6
0
2
49
展开一下拆分标准：一个小块要同时满足三条才算拆到位——
1）输入完整：开工前不需要再向人要资料；
2）输出可验收：完成与否能用测试、截图或 diff 直接判断；
3）失败可回滚：只改一个地方，出问题能单独撤回。
三条缺一条，就继续拆，别急着让 agent 开工。
1）输入完整：开工前不需要再向人要资料；
2）输出可验收：完成与否能用测试、截图或 diff 直接判断；
3）失败可回滚：只改一个地方，出问题能单独撤回。
三条缺一条，就继续拆，别急着让 agent 开工。
0
0
0
14
Agent 上线后最怕的不是模型变差，是没人看它的运行记录。没有 trace、没有每步工具调用的输入输出留档，出问题只能靠猜。我的底线是：每一次写操作都要能回答三个问题——谁触发的、依据哪条上下文、失败了怎么回滚。答不上来，就别让它碰生产。
0
0
0
27
agent 的工具权限就是新的 API key。我的做法是按「入职第一天的外包」标准给：默认只读，写权限一个个单独批，token 全部短命、过期自动吊销。你不敢把 deploy key 发给正式员工，就别塞给 agent。agent 出事，八成是权限给得太大，不是模型太笨。
2
0
2
61
nick retweeted
Want to try Muse? Here's my invite code: VBBM4X
Join Muse, then enter it in Settings > Redeem token within your first 48 hours. First come, first served — when it's gone, it's gone.
@ihm185 @iskakovdev @ansel8791 — passing it on in case it's useful. #AIAgents #AITools
Join Muse, then enter it in Settings > Redeem token within your first 48 hours. First come, first served — when it's gone, it's gone.
@ihm185 @iskakovdev @ansel8791 — passing it on in case it's useful. #AIAgents #AITools
5
1
4
541
Agree with the core point: disposable compute for agent fleets is now effectively free. The production caveat nobody prices in: 100 VMs each boot a fresh Claude Code that re-downloads context, re-authenticates, re-hydrates MCP state. The fleet is cheap; making 100 disposable agents coherent — dedup, result merging, no double-spends on the same task — is where the real bill lives.
We spun up 100 instabox.sh VMs and started Claude Code in all of them (with their desktops recorded)
400 vCPU, 800 GB RAM in total
All ready in 10s, and only $0.01 cost
1
0
1
88