所以软件会消失吗？未来是不是只有 Agent 工具和 Skills 呢？App 还会存在吗？我不知道，但相当长的一段时间内，两者应该是并存的关系。并且，所有的软件都应该对 AI Agent 友好，也就是说，AI Friendly，说白了，就是得给 Agent 做软件。 墨问也不例外，开始进入 Agent 的工作流了。最近俩月我们在做三四个项目，后续会陆续发布，第一个就是墨问官方 CLI 工具和官方 Skills 仓库。 地址在这里： 因为 CLI 依赖墨问的 API Key，目前已经开放给所有用户，包括会员和普通用户，只不过会员调用额度会更多一些。 详情阅读：

Codex 大踏步进击，入驻浏览器，它的能力得有这么多… 上周 OpenAI 给 Codex 做了个 Chrome 扩展，类似扩展 opencli 之前就搞过，控制浏览器呗，我感觉这不是啥重磅消息，直到我看了这个多 Agetn 控制 Chrome 的视频…… 1、用户给 Codex 下任务：让 4 个 subagents 用各自的 Chrome 标签页一起玩一个 drawing game。 2、Codex 启动本地网页应用，创建一个固定房间 CODEX4。 3、第一个代理先创建房间，另外 3 个代理再加入。 4、因为游戏需要多人同步开始，Codex 做了协调：等 4 个标签页都准备好后，再统一发出开始信号。 5、画图题目是 tiny lighthouse，也就是“小灯塔”。 6、四个代理分别在各自画布里画灯塔，有的画了红屋顶、黄光束、蓝色海浪，有的画了塔身、灯室、门和地面/水波。 7、最后 Codex 检查 Chrome 里的实际结果，确认 4 个 live PromptGrid 标签页都在同一个房间里，并且每个代理都完成了绘制。

1M 上下文时代，使用 Coding Agent 省钱计划 先说结论，怎么省钱呢，其实就是做好会话管理。、 1M 上下文是什么意思？就是在一次会话（session）里，模型能看见的大概 100 万个 token。最近发布的 GPT-5.5、Claude 4.6/4.7、Qwen 3.6-Plus、DeepSeek V4 等等都是原生支持 1M 上下文，这里面有几个关键的概念： 第一，在 Claude Code 这类 Coding Agent 里，上下文不是一句两句对话，而是一个大杂烩：系统提示词、长期记忆、调用过的工具、工具的输出、读过的代码文件、终端日志、以及你给它的各种指令，统统都会塞进去。模型每回答一次，都是在这一大坨信息里“分配注意力”，决定该看什么、不看什么。 第二，1 百万意味着什么？以前咱们都用 8K、32K、200K 这种上下文窗口，现在是 1M token，像什么呢？原来你桌上摊几份文件几本书就满了，现在你有了一个很大的仓库，全部代码库、长日志、好几轮调试过程，都可以同时装进去，模型一眼看穿，这就是所谓“1M 上下文时代”。 但仓库再大，有两个本质没变：1、大模型会被噪音干扰；2、你的钱会随着大量 Token 流失，达到一种花 Token 如流水的感脚。 很多人用硅谷的顶级模型，没跟人家寒暄几句呢， 5 小时的额度已经用得干干净净，这真是人生最大的悲剧：任务没做完，Token 花完 liao……

假期里看到 OpenAI 的 CEO 奥特曼发文说：Codex 正在经历 ChatGPT 时刻…… 这篇短文获得了 96 万阅读，看起来大家有点感同身受，Codex 自从更新了这个叫“Codex 全能型助手”的版本之后，开始大踏步前行，步履坚定，眼神中充满了圣地延安就在某个不远前方的坚定。奥特曼甚至狂妄的夸下海口，如果世界将只剩下两个 Coding Agent，那将是 Claude Code 和 Codex。你看，奥老师在激动之余，还是很严谨的把 CC 放在了前面，非常得体。 我现在 Claude Code 和 Codex 用的比较多，根据套餐、5 小时和周份额，做了精密的设计，一三五日 CC，二四六 Codex，灵活调整，走位飘忽，主要看一个烧字。

假期里看到 OpenAI 的 CEO 奥特曼发文说：Codex 正在经历 ChatGPT 时刻…… 这篇短文获得了 96 万阅读，看起来大家有点感同身受，Codex 自从更新了这个叫“Codex 全能型助手”的版本之后，开始大踏步前行，步履坚定，眼神中充满了圣地延安就在某个不远前方的坚定。奥特曼甚至狂妄的夸下海口，如果世界将只剩下两个 Coding Agent，那将是 Claude Code 和 Codex。你看，奥老师在激动之余，还是很严谨的把 CC 放在了前面，非常得体。 我现在 Claude Code 和 Codex 用的比较多，根据套餐、5 小时和周份额，做了精密的设计，一三五日 CC，二四六 Codex，灵活调整，走位飘忽，主要看一个烧字。

AI-native software engineering teams operate very differently than traditional teams. The obvious difference is that AI-native teams use coding agents to build products much faster, but this leads to many other changes in how we operate. For example, some great engineers now play broader roles than just writing code. They are partly product managers, designers, sometimes marketers. Further, small teams who work in the same office, where they can communicate face-to-face, can move incredibly quickly. Because we can now build fast, a greater fraction of time must be spent deciding what to build. To deal with this project-management bottleneck, some teams are pushing engineer:product manager (PM) some teams are pushing engineer:product manager (PM) ratios downward from, say, 8:1 to as low as 1:1. But we can do even better: If we have one PM who decides what to build and one engineer who builds it, the communication between them becomes a bottleneck. This is why the fastest-moving teams I see tend to have engineers who know how to do some product work (and, optionally, some PMs who know how to do some engineering work). When an engineer understands users and can make decisions on what to build and build it directly, they can execute incredibly quickly. I’ve seen engineers successfully expand their roles to including making product decisions, and PMs expand their roles to building software. The tech industry has more engineers than PMs, but both are promising paths. If you are an engineer, you’ll find it useful to learn some product management skills, and if you’re a PM, please learn to build! Looking beyond the product-management bottleneck, I also see bottlenecks in design, marketing, legal compliance, and much more. When we speed up coding 10x or 100x, everything else becomes slow in comparison. For example, some of my teams have built great features so quickly that the marketing organization was left scrambling to figure out how to communicate them to users — a marketing bottleneck. Or when a team can build software in a day that the legal department needs a week to review, that’s a legal compliance bottleneck. In this way, agentic coding isn’t just changing the workflow of software engineering, it’s also changing all the teams around it. When smaller, AI-enabled teams can get more done, generalists excel. Traditional companies need to pull together people from many specialties — engineering, product management, design, marketing, legal, etc. — to execute projects and create value. This has resulted in large teams of specialists who work together. But if a team of 2 persons is to get work done that require 5 different specialities, then some of those individuals must play roles outside a single speciality. In some small teams, individuals do have deep specializations. For example, one might be a great engineer and another a great PM. But they also understand the other key functions needed to move a project forward, and can jump into thinking through other kinds of problems as needed. Of course, proficiency with AI tools is a big help, since it helps us to think through problems that involve different roles. Even in a two-person team, to move fast, communication bottlenecks also must be minimized. This is why I value teams that work in the same location. Remote teams can perform well too, but the highest speed is achieved by having everyone in the room, able to communicate instantaneously to solve problems. This post focuses on AI-native teams with around 2-10 persons, but not everything can be done by a small team. I'll address the coordination of larger teams in the future. I realize these shifts to job roles are tough to navigate for many people. At the same time, I am encouraged that individuals and small teams who are willing to learn the relevant skills are now able to get far more done than was possible before. This is the golden age of learning and building! [Original text: ]