AI

AI 还在输出，我能插话吗？背后的两类协议 我想做一个 AI（人工智能）应用：它持续输出，我能中途补一句“换个方向”，还得保存任务进度。研究这个需求，先要分清两件事：消息怎么传，新指令什么时候执行。【关键词：#流式输出 #SSE #WebSocket】 01｜持续输出，靠什么传？ 常见的是两类协议： SSE（服务器发送事件）：基于 HTTP，服务端在同一条响应里持续发送增量内容。文字逐段出现，不用等整篇生成完。 WebSocket（双向通信协议）：连接建立后，双方都能主动发消息，适合频繁交互和实时音视频。 厂商要按具体接口区分，不能一个名字概括全部： 官方接口 使用的传输方式 OpenAI Responses：HTTP 流式模式 SSE Anthropic Messages：流式模式 SSE OpenAI Responses：WebSocket 模式 WebSocket Google Gemini Live：预览版 WebSocket SSE 负责单向下发，也能搭配另一条 HTTP 请求接收用户指令。能插话，不代表必须用 WebSocket。 02｜消息发到了，AI 就会马上改吗？ 我更关心的是这一层。假设 AI 正在写方案，我补一句“预算减半”，应用可以有三种处理方式： 打断：请求停止当前生成，再带着新要求继续。已完成的工具操作需要另行处理，取消生成不会自动撤销它们。 中途调整：接收新要求，到合适的执行边界再改方向。 排队：当前任务做完，再处理下一件事。 具体机制各家不同。例如，OpenAI 的中途调整接口使用 response.steer：先确认收到，等当前输出项和已运行的托管工具收尾，再在后继响应中加入新要求。收到指令，不等于指令已经生效。 SSE、WebSocket 解决传输；打断、调整、排队，属于任务调度。协议不会替应用做决定。 03｜连接断了，任务还在不在？ 还得看应用保存了什么。 我会把用户指令、已公开的输出、任务状态和事件序号存下来。重新连接时，先恢复记录，再补发缺失事件；重复送达的指令要去重。长连接不能充当数据库。 对我这个以文字任务为主的需求，我会先选“HTTP 提交指令 + SSE 接收输出”，把任务调度与保存做好。需要实时音视频或频繁双向交互时，再考虑 WebSocket。 聊天框里多一个输入入口很容易；让一句新要求在正确的时机生效，才是这件事的核心。 作者：猫咪不吃愚 资料核查：2026 年 10 月 29 日。本文为方案分析，未做接口实测；AI 辅助检索与起草，封面由 AI 生成。 ...

AI 写了 90% 代码后，Anthropic 怎么把 code review 做不崩 原文：How the Claude Code team does code review 作者：Addy Osmani, Morgan Westlee Lunt, Qing Wang（Anthropic Claude Code 团队） 来源：claude.dev 官方博客，发布于 2026 年 10 月 15 日 【关键词：#ClaudeCode #代码审查 #AI编程】 原文开篇连着问三个问题：每天 agent 产出这么多量，该怎么 review？还有人在读代码吗？真出事了谁来兜？ 这问题问得很准，因为 Claude Code 团队自己就是那个极端案例——Claude 写了约 90% 的 Claude Code 代码。我把原文和配套的工程博客、官方文档全过了一遍，最有价值的部分整理在这里。 01｜先看场景：AI 是主要作者时，review 为什么崩 三个数字摆出来，问题的量级就清楚了： Claude 自己写 Claude Code 约 90% 的代码 Anthropic 的 monorepo 每天落地的变更数，从 5 月的约 2,500 涨到 9 月的 30,000+（Claude Code 在独立仓库，不在这个 monorepo 里，但同样在承压） 6 月到 9 月，Claude Code 自己仓库的合并 PR 翻了一倍多，而需要 revert 的比例下降超过 40% 九成代码由 AI 写、每天三万次变更落地，人力逐行 review 在这个量级下不是"困难"，是"不可能"。 ...

Pi 的 Agent 循环：159 行，两个 while，四条退路 原文：pi-agent-core · agent-loop.ts 作者：Mario Zechner（pi-mono / pi-ai 作者） 来源：earendil-works/pi 仓库，@earendil-works/pi-agent-core v1.4.0 阅读环境：2026-10-26 对照 v1.4.0（2026-10-22 发布），agent-loop.ts 第 172–330 行 2026 年 10 月，我想把 Pi 接到自己项目里，顺手翻了一遍它的 agent 循环。 这个仓库半年里从 v0.62.0 涨到 v1.4.0，核心那个 runLoop 从 78 行长到 159 行，骨架却一个字没动。多出来的 80 多行，全是留给上层插嘴的。 【关键词：#Pi #Agent循环 #源码阅读】 01｜骨架：两个 while，各管一件事 Pi Agent 循环骨架：外层管队列，内层管 turn 函数叫 runLoop，在 packages/agent/src/agent-loop.ts 第 172 到 330 行。一个 while (true)（188 行）管外层，一个 while (hasMoreToolCalls || pendingMessages.length > 0)（192 行）管内层。 ...

AI 泡沫会怎么破？我担心的是回本太慢 我看好 AI 对生产力的长期影响，但对这轮资本投入有个担忧：技术进步的速度，和投资者赚回钱的速度，可能差得很远。【关键词：#AI泡沫 #生产力 #投资回报】 01｜用了多少，还不等于赚了多少 截至 2026 年 10 月 4 日，美国人口普查局调查中，23.8% 的企业报告过去两周使用过 AI。口径是任一业务职能，写邮件也可能算，不能理解成近四分之一的企业已经完成业务改造。官方数据 这个比例说明普及仍有空间，却不能单独证明泡沫。真正让我在意的是：使用能否持续，扣掉接入、审核和返工成本，还能省多少钱。 02｜需求是真的，投入也不小 微软 2026 年 7 月 29 日披露，Microsoft 365 Copilot 已超过 3000 万付费席位。愿意掏钱的需求确实存在。微软财报 同次披露中，第四财季资本开支达 410 亿美元，约三分之二投向以 CPU、GPU 为主的短寿命资产。这包含非 AI 业务，不能全算成 AI 的账，但设备更新的成本躲不过。财报电话会 假设 AI 帮企业省下 100 元，企业可能只愿付 10 元。竞争再把价格压低，生产力红利就更多留在用户手里。AI 很有用，供应商也可能赚不到预想的利润。 03｜泡沫可能破在预期落空时 如果这轮泡沫发生明显调整，我更倾向于这样的过程：企业续费和扩容低于预期，融资转冷，部分公司削减算力采购，扩建项目随之推迟。 不必等到收入下降。市场按翻倍增长给价，实际只增长五成，也足以触发估值下修。资金薄、债务重、客户集中的公司，会更难熬。 目前这些数据还不足以证明整个行业都被高估。我担心的是，资本把多年后的利润，提前算进了今天的价格。 所以我会继续用 AI，也继续看好它的长期价值；评价投资时，则更关心续费、毛利和现金流。技术值得期待，回本的账仍要一笔笔算。 资料核查截至 2026 年 10 月 19 日；本文含 AI 辅助检索与起草。 作者：猫咪不吃愚

这半年看下来，我反而更愿意先把云端 AI 代理用上 原文：OpenAI DevDay 2026 作者：Sam Altman 及 OpenAI DevDay 2026 keynote 团队 来源：OpenAI DevDay 2026，主旨演讲于 2026 年 9 月 29 日，旧金山 2026 年 9 月 29 日 OpenAI 把 Dot 推到台前那天，我就把 DevDay 完整回放看了两遍。我是个 30 岁的中国程序员——之前在互联网大厂烒过 996，现在在国企云厂上班；我关注这一年的体感，谈对"云端 agent"和"手机 agent"两条路线的取舍。你不同意完全没问题，下面这些都是我自己的体感、或看到了身边朋友跑过之后留下的证据。【关键词：#云端 AI 代理 #常驻智能体 #OpenAI Dot】 01｜云端 agent 到底是什么、和手机代理为什么差那么多 这一篇谈的"云端 agent"，我先把它的定义讲清楚——是一种常驻式的 AI 助手，但装在厂商分配给你的远程电脑上，不是装在你本地设备。你授权账号之后，它能直接登进 GitHub / 邮箱 / 企业 SaaS 这些云端服务，按你给的步骤替你跑任务：可以是一次性的（"今天帮我抓 30 个 trending 项目"），可以是长时盯梢（"盯着这张机票，低于 4500 美元就叫我"），也可以是每天早上 8 点做一份昨晚邮件摘要这样的连续工作。它最不寻常的一点是：你关掉 ChatGPT 它也在跑，你换台设备登录它仍在原来的上下文里——这一条就把"AI 跟你聊天"与"AI 帮你办事"完全划开了。 ...

适应 AI 时代：提高判断力和品味，让产出变多，也让自己变强 2026 年 10 月 2 日晚上，我和几位算法、产品同行吃饭，聊到很多校招面试人很会用 AI，却判断不了它的成果。这让我琢磨：借助 AI 做更多事的同时，自己的能力怎么跟上。【关键词：#AI协作 #判断力 #个人成长】 我更愿意把精力放在四件事上：选值得做的问题，判断方案的好坏，补自己的短板，把经验变成下次能用的工具。 01｜先选问题，再追速度 AI 能帮忙执行，目标却需要说清楚：为谁解决什么问题，做到什么程度就够了，哪些代价不能接受。 OpenAI 在 2026 年 9 月 16 日公布的研究中，持续观察约 6,200 名美国 ChatGPT 用户：涉及此前用过的跨职业任务的消息，占职业特定 AI 消息的平均比例，从 4 月的 13.1% 升至 7 月的 25.9%。这反映该样本的使用变化，不代表专业能力或生产率翻倍。研究报告 值得尝试的，是用 AI 扩大任务范围：例如程序员借助它分析用户反馈，再用真实需求检验。先选有价值、能验证的小任务，不急着给自己换个“全能”的头衔。 先判断事情有没有价值，再让 AI 放大投入的效果。 02｜基础检查对错，品味权衡取舍 判断力检查结果是否可靠；品味决定方案是否值得采用。Ethan Mollick 在 2026 年 9 月 18 日的博文中强调，深厚专长、跨领域知识、品味与主动探索，能帮助人更好地利用 AI。这是他的观点，并非就业保证。原文 拿一个假设的订单服务举例。接口能下单，还得检查重试会不会重复扣库存、写入失败怎么恢复。理解并发和数据一致性，才知道该查哪里。 维护成本不会因为架构图漂亮就打折。用户少绕路、团队好维护，都是比“看起来高级”更具体的取舍依据。 两个模型都说对，不等于两份独立证据。关键判断仍要回到资料、实验和用户反馈上。 03｜交付借力，学习保留练习 熟悉的任务，知道怎么验收，就让 AI 多做。自己解释不清的概念，先独立想一遍，再请它挑错。 Anthropic 在 2026 年 1 月 29 日公布的编程学习实验中发现，AI 辅助组的即时理解测试表现更低；主动追问概念、要求解释等使用方式表现较好。这是小样本、短期实验，不能推断长期能力必然下降。研究说明、论文 ...

国庆假日里想明白一件事：编程语言对 AI 来说，可能本身就是低效的，我们还在纠结编程语言吗？ 国庆第 1 天，没怎么出远门。下午我看着窗外，想着最近半年跟 agent 协作下来的体感，正好网上还在争论"AI 写 Java / Python / Go 哪个质量好"，忽然意识到一件事——这些争论，可能问错了。编程语言对 AI 来说，从一开始就不是它的母语。【关键词：#AI编程 #AI原生工程师 #上下文设计】 maybe，我们未来不再关心使用什么编程语言，AI的对语言的学习和使用是远胜于人类的，只要AI逻辑严密，AI或许会有自己的语言去驱动及驱动机器执行二进制程序吧。 01｜编程语言从来不是给 AI 设计的 打开 IDE 看到的 Python、Go、Java、JS 这些语言，它们被人为的"可读性、命名空间、类型系统、设计模式"绑了一身——这些是好东西，让我们能跨团队协作、能 review、能维护。 但 AI 不吃这一套。它不读注释、不在意缩进、也不会被你精心取的命名打动——它真正消耗的是 token、是上下文、是注意力分布。 最近一次让我愣住的：我让 Codex 改一段 Go 的并发代码，它把 channel、mutex、context 整段翻完，最后只用了两行；而我换成一段伪代码 + 关键约束描述喂过去，它一次就跑对了。 那一刻我才反应过来：AI 时代的"语言"，正在从"语法正确、人类可读"悄悄转向"信息密度高、上下文清晰"。Anthropic 内部数据里那 27% 的"agent 原本不会做的新工作量"——翻译需求、设计 prompt、整理上下文，本身正在变成新工种（Anthropic 研究页）。 02｜AI-native 工程师的默认单位，悄悄变了 借假期想明白的第二件事，跟我自己更相关——所谓 AI-native，不是会用 Cursor/Codex，是你脑子里默认的颗粒度变了。 老一代工程师脑子里装的是行、函数、模块；我自己这半年越来越意识到，AI-native 工程师脑子里装的应该是上下文窗口、任务切片、可验证的契约。 具体到每天的工作里，是三件事： 任务切片——把一个模糊需求拆成 agent 一次能跑完的小块，而不是把 2000 行的 PR 整段扔过去； 可验证的契约——每个任务都自带验收标准：什么算"做对"、什么算"做错"，让 agent 自己跑测试； 上下文设计——知道哪些信息 agent 必须看到、哪些是噪音、出错时才补什么。 说白了，AI-native 工程师写的不再是代码，是给 agent 跑的"剧本"。 ...

用了半年 Agent 之后，我对工作开发与运营的 5 点新观察 马上要国庆了，简单回顾下过去半年的AI Coding：我是 2026 年 3 月开始把 Codex + Cindy 当主力、混着 GLM5.2（国产）和自建 agent 编排一起用的开发者。下面 5 点，全是我身边真实发生、或交叉核实过数据的事。【关键词：#Agent #岗位变化 #代码开发 #AI趋势】 01｜前后端 title 在合并，但合并方向不是"更全栈"，是"更靠近 agent" 放数据：Salesforce CEO Benioff 2025 年公开不再招新工程师（Times of India）；Cognition 团队 15 人，每人带 5 个 Devin 跑任务，自家代码库 89% 提交来自 agent（agentmarketcap.ai）；Anthropic 内部 60% 工作有 Claude 参与、27% 是 agent 原本不会做的新工作量（Anthropic 研究）。 title 在合并，意味着"更靠近 agent 的工作方式"。 02｜中间层不是被"砍掉"，是被"打散" GitLab 2025 年裁 14%、退 22 国，研发团队从 30 个重组为 60 个跨职能 pod（LinkedIn 报道）；Skai 砍中间层效率从 7–12% 跳到 500%；HaxiTAG 33 个工程师只配 1 个 team lead。 中间层没消失，是被打散到 pod 里去了——"管人"的中层在贬值，"管 agent + 管判断"的中层在升值。 ...

周末用SQLite，我给 AI Agent 配了一个文件型"本地大脑" 【关键词：#SQLite #AI Agent #本地存储】 做一个 AI Agent 项目，需要给 agent 配上持久化层：要存会话历史、用户记忆、工具调用日志、任务队列，还要能跑简单检索。我没拉一套数据库服务，就用一个 SQLite 文件——一个 .db 把 agent 的所有状态都接住。两个月跑下来，稳定、可备份、可调试。 将agent执行的环境上下文信息，在SQLite存储，多agent可共享SQLite里的数据，SQLite 让 agent 的"记忆"和 agent 本身活在一起，不将各个数据分散到不同文件里。 PS : 这仅是短期实践的心得，后续AI的进步，SQLite也行会被抛弃。 01｜先看 SQLite 自己怎么说自己 打开 sqlite.org 首页，SQLite 给自己的定义只有一句话： SQLite is a C-language library that implements a small, fast, self-contained, high-reliability, full-featured, SQL database engine. SQLite is the most used database engine in the world. 翻译过来就是：小、快、自给自足、高可靠、功能完整的 SQL 数据库引擎。官方口号更短——"Small. Fast. Reliable. Choose any three."（小、快、可靠，三选三）。 ...

AGENTS.md 写对一次 ≈ 一次模型升级：60k 仓库总结的 5 段结构、6 个模式、5 类反模式 一句话定位：README 写给人看，AGENTS.md 写给 AI Agent 看。 AGENTS.md 不是文档，是 Prompt。你不是在写文档，是在做上下文工程。 —— Augment Code 工程博客 【关键词：#AGENTSmd #AI编程 #上下文工程】 01｜和模型强弱到底是什么关系：三种打架的结论 "我用了 Claude Opus 还需要写 AGENTS.md 吗？"——最近这一两个月，被问到这一句的次数，比过去一年加起来还多。 网上数据打架，我整理出三种主流结论。 我的判断一：好的 AGENTS.md ≈ 一次模型升级。Vercel 的 Next.js Evals 这套基准是所有数据里跑得最干净的——没有 AGENTS.md 的时候，Claude Sonnet 4.6 通过率只有 67%；加一份好的 AGENTS.md 之后直接到 100%。GPT 5.3 Codex 同样从 86% 拉到 100%。最反直觉的一行：——一份好文档的杠杆，比一次模型升级还大。 判断二：弱模型受益更大，但强模型也吃这套。The Prompt Shelf 综合 60k+ 仓库数据后画了一条更细的线——弱模型缺乏世界知识，必须靠显式上下文才能在同一个代码库上工作；前沿模型能自己推断大部分约定，但对非显而易见的项目约定（部署步骤、内部 API、仓库特有坑）仍然需要 AGENTS.md。边际价值不同，但没有哪个模型可以裸奔。 判断三：差的 AGENTS.md 比没有还糟。Augment Code 的实测 有点打脸：同一份 AGENTS.md，任务 A 提升了 25%，任务 B 反倒掉了 30%。——规则一旦自相矛盾，模型就开始犯傻。 ...