第一次是在 muse 上看到 main chat/side chat 的说法，这两天发现 grok bot 和 town 也都上了类似的设计，感觉确实是个兼顾易用性和效率的设计，有希望成为接下来的主流范式，说起来其实和 Moxt 里的 Momo/teammate 也有点异曲同工之妙。

最近被 ChatGPT 降智搞得很烦，目前为止看到最准确的测试方案是 xqy2006.github.io/ModelTrace…， 参考这个项目的实现把核心逻辑放到了一个 gist 里，你只需要对 agent 说以下指令来测试实际用到的模型，支持主流 GPT/Claude 模型 follow instructions in this gist gist.github.com/fankaidev/0e…

测试了一下，在被降智的 ChatGPT 账号里用的 dot 跑 Codex，也是被降智的～

GPT-6.1 采用了和 Opus-5.5 相同的策略，input/output 价格不变，但是 cache 价格砍了一半，这个在真实的 workflow 里也差不多能够让整体成本下降 25%。 不过这一波 opus/sonnet 表现确实亮眼，GPT 哪怕这么着急发布依旧被盖了一头。还是感叹下 Gemini Pro，去年下半年的人类之光，现在毫无疑问是智能洼地了。 moxt.ai/w/4rzdzhjy/cd90f262-…

ChatGPT Space 发布了，巨头们终于要认识到团队 workspace 的重要性，这对于 Moxt 未必不是好事。虽然 Moxt 半年前就做了这个事情，但是一个创业团队要讲故事还是太难了。现在有巨头在前面教育用户，以后我们再来讲这个事情可能会容易的多。

Manus 是给被折腾过的老用户送了半年 pro 吗？ @ManusAI

在 agent 执行流程中，input token 一般是 output token 的 200-500 倍，而 cache rate 一般好的 harness 能够到 90% 左右。 以这个比例来计算，output token 在整个成本中的占比其实很小，不超过 5%，所以大模型的真实成本几乎只需要看 input 和 cached 的价格即可。 而按照 90% cache hit 的经验值，token 的实际价格几乎可以用下面的公司来简单估算： input price + 10* cache hit price， 按照这样的估算，Fable/Opus/Sonnet 的 token 实际价格比例大体上是 12.5:6:4。 而上一代 Fable 5/Opus 5/Sonnet 5 按照同样的公式来估算其实是 20:10:4，由此可见新一代模型并不只有 GPT-6-sol 腰斩，Fable/Opus 其实也是接近腰斩的。 当然这里没有考虑不同模型对于不同的任务所消耗的 token 数量不一致，不过影响这个因素又太多了，包括不同的 effort 设置，就很难精确比较了。

前段时间是各类办公 agent 群雄混战，最近 personal agent 又突然大火。之前就试过 Grok Bot，今天又试用了一下 Meta 的 Muse 和 Manus Cue，简单聊聊自己感兴趣的点。 这几个产品应该都算是新一代的个人 agent 产品，一些共通的点包括： - 相比于 Codex/Claude 这样明确只把 AI 能力包装为工具的产品，这些产品显然都强化了 Agent 的身份属性，尽量让用户感觉对面是一个人，而不是一台机器。虽然底层还是 Instructions/Memory/Skills，但也尽量把这些入口藏得稍微深一点，避免显得过于技术化。 - 毫无疑问，很多设计上都还有 coding agent 的影子，比如让 agent 关联到一台机器上。但它们都不再要求用户提供一台永远在线的电脑，而是由厂商直接提供一台云端电脑。听起来，一台持续运行的云端电脑成本会很高，但实际成本可能比大部分人想象的低很多，因为只需要给用户一台虚拟机，在不使用的时候休眠即可。我们在 Fly.io 上搞一台自动休眠的机器，在日常 workload 下，一个月可能只需要几美元，大厂自己管理集群的成本应该更低。像 Muse，财大气粗，好像并不着急让用户付费。 - 功能上算是新一代的 OpenClaw 吧，也都希望接管用户的各种日常信息流，并让用户可以随时随地访问。Muse 大火，好像是找到了自动帮用户取消订阅这类痛点，其他 personal agent 的功能其实也都大差不差。从技术实现上看，这些 integration 已经很常见了，当然，要把细节打磨好，并平衡便利性和安全性，也并不容易。 我更感兴趣的，是大家对于 Agent 的抽象还是有很大区别。 - Grok Bot/Cue 都是多 agent 的设计，用户可以定义多个 agent 的身份，可以和这些 agent 私聊，也可以把多个 agent 拉到一个群组里协同工作。 - 但和各类办公 agent 相比，这两个产品有一个不一样的设计：一个 agent 似乎只有一个 thread。之前，不论是 ChatGPT/Claude/Manus 这类没有 agent 身份抽象的产品，还是支持定义 Agent 身份的产品（比如我们的 Moxt），都允许你对一个 Project/Agent 开多个 thread 来并行工作，这在工作中也是非常必要的。Grok Bot/Cue 不一样，agent 边上没有一个 new session 按钮，你只能对着同一个窗口一直聊。即使把一个 agent 拉到群聊里，这个 agent 其实还是在同一个 thread 里处理来自多个群聊的消息，再通过工具回复到各个窗口。 - 其实我目前还没有完全想明白这个设计。当然，它们肯定具备在后台开多个 sub-agent 并发执行任务的能力，但至少从前端用户的感受来看，仍然是单 thread 的抽象。但至少在工作场景中，这让用户很难围绕同一个 agent 展开多个独立的并行工作，除非定义新的 agent。好处则是，你在任意窗口里聊过的信息，agent 都很清楚，因为背后对应的是同一个上下文，这确实让这个 agent 有了更好的真人感。 - Muse 又是另外一种设计：只支持定义一个 agent 身份，但支持开多个 thread，而且明确区分了 main chat 和 side chat。也就是说，它希望大部分情况下，你只需要在 main chat 里和它聊天，保持完整的上下文；只有在有明确的支线任务时，才需要开一个 side chat 来处理。我理解 Muse 可能是希望面向更加大众化的市场，所以也尝试把概念设计得更精简一些。Grok Bot/Cue 的受众群体则相对更前沿一点，因此引入了更复杂的 agent 协同机制。 总体而言，像 ChatGPT 这样任务式的多 thread 设计，确实少一些真人感；Grok Bot/Cue 这样的单 thread 设计，在使用上又明显有些限制。Muse 对 main chat 和 side chat 的区分算是一种平衡，但毕竟又引入了一个维度的复杂性，是否会成为未来的主流范式，现在也不好说。未来的 Agent 抽象和范式如何演进，还是一个有趣的问题。

看到很多人已经有运行 e2e 测试都意识了，大家也都会碰到一些问题，比如运行时间长、成本高，简单说一些我们的缓解措施： 1. 使用本地 runner，搞一些配置好点的机器来跑测试，成本比 github cloud runner 便宜很多。同时需要控制一下测试并发度，避免打满了机器谁也跑不过。 2. 尽量设置精准的代码依赖，测试进行相对细粒度的分组，代码改动的时候只运行受影响的测试组 3. 测试分层。我们把测试分成了 P0/P1/P2，CI 过程改动多一般只跑 P0 的测试，merge queue 里跑的多一点 P0+P1，P2 的测试则是有一个定时任务每半个小时才执行，这种方式能够砍掉大半的测试负载。如果 P2 测试有失败会有 agent 自动介入处理，如果是 flaky test 默认就直接先注释掉，如果是逻辑错误就自动创建 fix pr 然后通知 owner 处理。 4. 我们的测试都是 BDD 驱动的，除了 PR 里要求带上测试都相关修改，每天晚上 agent 会自动扫描过去一天修改的所有逻辑和测试，重新整理一遍，调整测试级别，删除冗余或者低效的测试，避免整个测试集无序膨胀。

Had a deep conversation with a startup team recently that has been using Moxt extensively to build an AI-native way of working. They shared a few lessons that I think are worth writing down. 1. AI-native is not about making existing workflows faster. It is about redesigning the workflow itself. If AI is only used as a faster search engine, writing assistant, or coding assistant, you may get a 30% or 60% productivity improvement. That is useful, but it is not AI-native. To get an order-of-magnitude improvement, the workflow itself has to change. 2. Everything needs to become queryable. Agents should be able to access the information they need at any time. Meetings have transcripts. Decisions have documents. Tasks have states. Discussions leave a trace. Critical context should not live only in someone’s head. Traditional teams often synchronize through an N×N communication network: everyone talks to everyone else. An AI-native team starts to look more like N×1: everyone synchronizes with the same shared context. 3. Agents should be involved from the first sentence. Don’t finish thinking, writing, or planning first and then hand the result to AI for optimization. Bring the agent in as soon as the idea appears. Let it participate throughout the process. Over time, humans can move further into the background and step in only when judgment is actually needed. 4. When you hand something to an agent, hear its view before giving yours. If you provide your own framing too early, the model can easily become anchored to it and spend the rest of the conversation finding arguments that support your position. Let the AI form an independent view first. Then humans can choose, challenge, correct, and decide. 5. Minimize human-in-the-loop work for objective tasks. Facts, information retrieval, synthesis, organization — these should increasingly be handled by agents. Human bandwidth should not be spent confirming things that can be objectively verified. It should be reserved for tradeoffs and judgment. This also changes how teams discuss proposals. A surprising amount of disagreement comes from an unclear or inconsistent understanding of the facts. Let agents align the “fact layer” first. Many disagreements disappear once the information asymmetry is removed. What remains is where humans should make the call. 6. Humans should answer judgment questions, not generation questions. The human role is shifting from producing possibilities to choosing among them. AI expands the option space. Humans define the direction, standards, and tradeoffs. The bandwidth for judgment is much higher than the bandwidth for generation. But this creates a new bottleneck too. Once AI accelerates execution, human decision-making capacity often becomes the constraint. A person who used to make one meaningful decision a day may suddenly need to make twenty. 7. Every output has to flow back into context. When an agent finishes a task, the result, the process, and ideally the reasoning behind it should return to the team context and become input for the next cycle. Without that feedback, there is no real loop. If I had to summarize the whole idea in one sentence: An AI-native team is not a team where everyone uses AI. It is a team whose operating model is redesigned so that information is queryable by agents, agents participate deeply in the work, the factual layer is handled by AI, humans focus on judgment and tradeoffs, and every result continuously flows back into shared context. I also asked them a more practical question: What is the biggest pain point in building this workflow with Moxt today? Their answer was very specific: local agents are still not fully connected to the loop. In software development, people still spend a lot of time in local tools such as Claude Code and Codex. The team context, tasks, discussions, and decisions may live in Moxt, while a large amount of execution context is created locally during development. That means the loop is still incomplete. People have to manually synchronize context between the team workspace and local agent environments. This is one of the problems we want Moxt to solve next: make local agents a natural part of the team workspace, so context, execution, and feedback can finally become one continuous loop.

Moxt 一直在追求的目标，就是更好地沉淀和利用团队的 Context，让 Agent 变得更聪明，最终能够真正成为团队中的 AI Teammate。 在做 Moxt 的过程中，我们越来越意识到，团队最重要的 Context，可能不只在文档里。 从用户实践来看，文档协同并不会自动带来有效的团队 Context。很多团队的共享文档库，用着用着就会积累大量临时文档和过期内容。甚至有用户宁愿在每次任务开始时，重新把背景讲给 Agent，避免其被错误的 context 带歪。 这个问题我们也还没有解决方案，对于文档的管理各个团队的实践很不一样，但目前都还是需要有主动的熵减措施。但这让我们重新思考：如果构建更好的团队 Context。 文档、代码、知识库当然重要，但真正影响团队产出的，很多时候发生在其他地方：一次会议里的判断，一段讨论中被否掉的方案，大家为什么接受或拒绝一个结果，以及最常见的就是大家每天和 agent 的交互过程。 这有点像现在所谓的开源模型，其实只是开放了权重，但真正重要的资产，是训练数据、筛选方式、反馈过程、失败经验和具体流程。而后面的这些东西并没有一起开放。 团队也一样。文档记录了团队知道什么，会话和互动则记录了团队如何判断、如何协作、如何处理分歧，以及如何把一件事做成。把这些过程有效沉淀下来，才能让 Agent 慢慢学会这个团队是怎么做事的，逐渐成为真正的 AI Teammate 的关键。

确实还是有一点感概，这两年看着 Devin 一直都是面临巨大的压力，很多时候已经觉得是 nobody 了。这一点确实很佩服 Devin 团队，在这样的压力下稳扎稳打，又到了一个新高峰。 算起来老对手 Cursor 过去好长一段时间日子也不太好过，大家都觉得会被 Claude Code 革命，也是一步步挺过来了并且有了非常不错的创业成果。

对新模型的发布确实有点疲劳了。现在前沿模型的差距在拉近，在 coding、推理、Agent 任务上多数团队已感受不到决定性差别。开源模型（DeepSeek、GLM、Kimi 等）在价钱更低的情况下，对绝大部分任务也都非常能打了。OpenAI、Anthropic 曾拥有的那种近乎垄断的领先优势，很难再复现。 我们的判断：以后团队不会只用一个模型或一种 Agent：不同任务需要不同能力与成本；coding、研究、内容等领域会有各自的 Agent；一部分执行在云端，一部分必须在本地或企业环境；前沿团队不会愿意把工作方式永久绑定在单一供应商上。