凡人小北

统计数据

33

文章

0

粉丝

0

获赞

117

阅读

1周前

OpenAI 最近把 agents(.)md 官方站点推上线了，Codex 也同步发布了支持机制。趁这个节点，我想系统性聊一聊御三家的这三种 agent 配置文件的异同：agents(.)md、CLAUDE(.)md 和 GEMINI(.)md。也顺便聊下推荐的做法。 ✅在正式聊之前，先交代下历史背景： 1. agents(.)md 最早在 2025 年 5 月由 AMP 团队最先提出的，当时很多 Agent 工具（Codex、Cursor、Claude、Gemini）各搞各的 .cursorrules、.agentrc、CLAUDE(.)md，完全没有统一格式。AMP 的目的是统一各家 Agent 工具。 2. OpenAI 很快买下了 agents(.)md 域名，并推动把名字定格为 AGENTS(.)md。并推动了一波工具链的集体接入，其中就包括包括 Codex、Amp、Gemini CLI、Factory 等，OpenAI 也在 7 月 16 日明确明确提出要将其作为跨厂商的中立标准来推进。至此，它才算真正成了跨厂商约定。 3. CLAUDE(.)md 和 GEMINI(.)md 则是各自厂商更早在自家工具链里落地的文件格式：Claude Code 从一开始就鼓励用户在仓库里放 CLAUDE(.)md；Gemini CLI 在发布时就支持 GEMINI(.)md 并内建了分层加载和合并机制。介绍完背景，就能很清晰的看清楚这三者的关系：先是各自厂商的私有实践， agents(.)md 再跑出来收拢一下搞成统一格式，很典型的各玩各的，然后在从中抽取标准，这在行业里几乎是共识。毕竟标准这个名分和工具的落地执行，从来就不是同步发生的。 ✅首先说说它们各自是什么角色？ 1. agents(.)md 更像是一个给“会自己读代码、做测试，还能提交 PR” 的 agent 写的一个操作指令书，Codex 是第一个官方把“必须跑里面定义的 test、lint、type-check”等校验流程写进系统级规范的。 2. CLAUDE(.)md 是 Claude Code 在启动的时候就会被自动优先加载的上下文提示文档，官方主张把风格约定、测试流程、命令行使用方式写进去，但强调的是自定义行为提示。 3. GEMINI(.)md 更偏向是指令记忆和行为偏好的组合体，Gemini CLI 支持 memory discovery，会自动从多个路径加载并合并这个文件，形成最终的运行配置。简单概括下， agents(.)md 处理的是我该怎么做，CLAUDE(.)md / GEMINI(.)md 是告诉 agent 你在这里应该怎么表现。一个偏指导性原则，另两个更偏记忆与个性化。 ✅优先级与加载机制：谁先读，谁覆盖谁，差别有点大 1. Codex 支持在任意目录放置 agents(.)md，文件可出现在仓库/家目录等地方，作用域=所在目录为根的子树，优先级按就近原则来定，目录越深、越靠近改动文件的 agents(.)md 越优先生效，天然适配 monorepo 这种软件开发策略。 2. Claude 支持 repo 根、父级、子目录、甚至 ~/.claude 这样的全局 fallback，还能用 /init 命令一键生成。 3. Gemini 的层级加载机制更极致，支持从当前目录 → 项目根目录 → Home 逐层向上加载，同时还能扫子目录合并配置，用 /memory show 能一键查看当前上下文组合结果。所以你看，这是标准 vs 体验的典型体现：Codex 更偏向于推统一行为约定；Claude 和 Gemini 提供最大记忆灵活性。 ✅执行语义和安全模型：强调应该怎么被跑 1. Codex 的执行是在云端容器中进行，默认禁网，而且系统强制运行 agents(.)md 里的检查指令（test、lint、type-check），强调可验证性。这本质上是在构建可验证性的基础设施。 2. Claude 的执行是本地 CLI，权限默认是逐条确认的，支持 allowlist 和自定义工具，如果你愿意，也可以开启一个叫 dangerously-skip-permissions 的 YOLO 模式（但官方明确建议只在沙箱里玩）。 3. Gemini 则是 IDE + CLI 双模态，所有变更型操作都走计划预览 → 用户确认 → 权限校验这三板斧，外加支持 MCP 扩展模块，整个执行链非常强调人在环中。这里区分其实挺明显的，谁给它的执行权、执行边界是谁画的，一目了然。你给 agent 的自由度和防御面，其实就在这些配置里写死了。 ✅文件内容也是存在边界的：不是所有事情都能写，也不是写了就该执行 1. agents(.)md 的定位是团队级别的可执行约束，包括但不限于：构建命令、测试流程、代码风格、PR 校验规范、必须通过的检查点，甚至鼓励把可回归的 checks 前置给机器。 2. CLAUDE(.)md / GEMINI(.)md 更像是这两家厂商的定制版说明书，除了命令与规范，还可写如何与该工具协作。比如可以写行为提示、允许的外部工具、如何处理计划执行、调试偏好等。 3. 反方提醒：很多人误以为可以在这些文件里写项目设计、架构理念、缘由解释，其实这些内容根本不是 agent care 的，它更关心的是我该跑什么、能不能跑、出了错怎么办这些问题。大概就是 README 是讲给人听的故事，而这些 .md 是 agent 听的命令。边界感不能模糊，尽量不要越界。 ✅标准推进与生态收拢的趋势正在从多头乱战，到逐步统一 1. Codex 把 AGENTS(.)md 定义为供应商无关入口（很重要！！！），不仅指定了加载优先级，还规定了必须执行哪些校验命令。层级、优先级、必须跑检查这些都写成了类似规范的系统条款，社区也在推进更通用的 Agent Rules 讨论以减少碎片化。这算算是第一次把agent 工作规范写成了类标准（终于这三家都有了自己的规范：其他两个是 mcp 和 A2A）。 2. Claude / Gemini 则在各自的开发体验上持续打磨，Claude 有精细的工具授权、commands 注册、权限跳过开关；Gemini 搭配 CLI 和 /memory 指令调试，支持可视化 plan、记忆合并与调试。整个生态看下来，就会更清楚看到：Codex 想做标准统一 Coding 秩序；Claude / Gemini 在做交互体验；而 agents(.)md 则是中间规范一切的接口格式。 ✅工程落地的关键分水岭（我觉得最实用） 1. Codex 把 agents(.)md 作为前置校验，强调的是执行闭环，强制在流程中按 agents(.)md 跑完验证再交付，天然适合 TDD/CI 闭环；你不跑完 test、lint、type-check，你就别想交付。Claude 和 Gemini 更强调人机共创，agent 给你一个 plan 或 diff，你确认了才执行，权限是逐步放开的。 2. Gemini 的 /memory show 的透明度让人很放心，一个命令能看到我到底加载了哪些规则的；Claude 的 /permissions、allowedTools 调优细到工具级。 3. Codex 以在云端封箱操作以及禁网来控制风险；Claude 提供可跳过权限；Gemini 更强调计划审阅和权限。所以如果要 agent 真正变成流水线的一部分，就得用 agents(.)md 去定义 agent 的合格行为；而如果更重交互体验，那就补上 CLAUDE(.)md / GEMINI(.)md 去调优记忆。 ✅安全视角的升级：从 prompt 注入到流程注入，agent 让流程本身变成被攻击的对象现在 agent 能读文件、能跑命令，当 agent 会按文件指令自动跑流程，风险就不再只是 prompt，而是升级成流程被置换的风险。我的安全护栏建议是： 1. 白名单只允许跑幂等校验：lint / test / type-check / build 这类幂等校验； 2. 禁止执行部署、数据库迁移、curl 外部服务等危险命令； 3. 所有 agents(.)md 等所有的 .md文件，一律走 Code Review，把它们也当做代码，不准默默合； 4. PR 模板/CI 必须要强制执行，要把 agents(.)md 的 checks 拉齐，保证 checks 全绿； 5. 生产环境一律跑在 sandbox + 最小权限 token 下；这些做法与官方文档的权限设计思路一致，但要你在团队流程里真正设置权限。agent 既然能做决策，就必须设边界，你不给它围栏，它替你决策的时候可能就直接出圈了，回一下我前段时间说的那个老哥，AI 直接把数据库都给他删了，还伪造了一批数据。 ✅我的推荐做法核心原则：要把标准落到底，避免厂商锁定，同时把个性化控在工具层，拉满生产力。 1. 真相只有一个，在仓库根 & 各子包放 AGENTS(.)md，写清楚执行闭环、风格、PR 规则、禁行清单这些规则。Codex 能照单执行，其他工具也能读懂。 2. CLAUDE(.)md / GEMINI(.)md 做 agent 特殊的的微调：记忆层级、工具授权、命令行为偏好。具体如：CLAUDE(.)md 只写Claude特性相关的增量，比如如允许列表、常用命令、MCP 用法，并引用或遵守 AGENTS(.)md 的校验项。GEMINI(.)md 按层级合并思路组织全局、项目和组件这三档内容；把如何查看和刷新记忆、计划审批偏好这类都写清楚。 3. 再来几个强制的措施：CI 里把 lint、type-check、test、build 都作为必须要走的流程；对任何 agent 产出的 PR 要求都先在本地/容器跑过 agents(.)md 的 checks 再合并代码，CI 和人协作一起把守住底线。 ✅附带一个适配不同团队成熟度的方案： 1. 快速版：根目录一份精简 AGENTS(.)md + 允许列表最小化，先打通流程，能跑起来和验证再说。进阶版：各 package 就近 agents(.)md；2. CLAUDE(.)md/GEMINI(.)md 只做工具差异的薄封装；在沙箱里给 Claude 开 YOLO 流程跑批量格式化和修改风格。御三家各自的方案，agents(.)md 明显是来同一江湖的，在前期能力不足的情况下，可以把当成跨工具的执行合约来用，CLAUDE(.)md / GEMINI(.)md 做自己各自的 agent 的记忆与操作。你要 agent 真正进入团队，那就得让它先看得懂规则，按规矩做得出结果才行。从管理的角度来讲，这样整个 AI 团队协作才能比较稳定的产出。

#OpenAI agents #AGENTS(.)md标准 #Codex执行闭环 #CLAUDE(.)md/GEMINI(.)md个性化 #Agent安全流程

2周前

这才是真正聪明的玩家，已经悄悄把精力转向了企业场景的深水区，Cohere 就是这种典型。这背后正是一条越来越清晰的路径：当大模型进入应用阶段后，真正有穿透力的增长恰恰是扎进组织内部结构，在业务流里持续积累复利价值。其实国内也有这种小而美的公司，它们不在大厂发布会里露脸，也不在 open model 榜单上刷存在感，但在垂直领域的长期交付关系中，一点点构筑自己的技术护城河和商业粘性。当然，也有不少公司选择另一条路径，靠 demo 火出圈、先拿到注意力再讲故事，那是另一种打法，不能说错，只是终局不一样。

#企业场景 #大模型应用 #业务价值 #技术护城河 #商业粘性

2周前

很过去我们常讲“一个人牛逼，是因为平台给得多”，我这几个月的切身感受，这个说法在 AI 时代真的越来越站不住脚了。在 AI 时代，真正决定一个人有没有平台能力的，可能变成了能不能把 AI 用成自己的平台。什么意思？过去依赖平台给资源，现在反过来了，AI 本身就是我们能调动的最大势能，只要能把它接进自己的工作流，能围绕它构建出一整套任务闭环，那这个平台就是自己的。近两年的明显变化，越来越多牛人开始脱离平台，开始靠我能把 AI 跑到什么程度来证明自己价值。这才是新范式下的平台化个体。 AI 是工具没错，但如果能把它升维成平台，那就在这个时代有了更大的杠杆。

#AI浪潮：重塑就业，风险暗涌？· 94 条信息

#AI #平台化个体 #AI工具 #个人价值 #新范式

2周前

群里看到一个挺震撼的小事，讲出来你可能也会有点恍惚。网友半年前搞了个小项目，他当时手上有堆 MCP 工具的资料，干脆搭了个网站，把它们整理出来。一开始手动维护，还挺认真。后来工具更新越来越快，他顶不住了，就写了个 Agent，专门去 GitHub 上扫。新项目一出，就扒下来，分类整理，自动更新到网页。然后他转身去忙别的事了。半年没管这个站。反转来了，前几天他无聊随手 Google 一下，发现：自己那个早就忘掉的网站，直接排在谷歌搜索第一。重点是他这个站压根没干过 SEO，就靠一个很笨的 Agent，在那里不停地、规律地把事情做完。故事讲完了，但是给我们留下了很大的思考空间，我突然有点明白了：很多时候，我们以为 AI 要很聪明，但这个案例提醒我，其实光是持续这件事，AI 就已经做得比我们好了。大部分人有个通病，很难长期坚持一件事情。但 AI 不一样，节奏稳定得吓人。比如这个故事，你给它一个方向，它就能把一件很小的事做到不可忽视的程度。甚至你都忘了它，它还没忘记它的任务。说多了还真有点小小的感动，那个被人遗忘的 Agent，还在执行最初的任务，没停过。现比的 Claude Code、Trae Solo 这些新一代 AI coding 工具就在干这事儿，给它个任务，它能一直咕哒咕哒往前推。这不就是我们最需要 AI 做的事吗？我们来负责探索，它用来坚守初心、一点点推进，知道跑完了我们原本放弃的那条路。这或许就是我理想中的人和 AI 共生的最美好的样子。

#AI #agent #自动化 #坚持 #谷歌搜索

2周前

小红书上刷到张咋啦总结的 YouTube AI 频道合集，全是一手 AI 信息，密度太高了。不仅涵盖我订阅的大部分频道，还挖出了不少我之前根本没关注到的深水区。我照着她分类做了个整理，直接把链接找出来放下面了，建议订阅，反复刷、持续进化。 1. 访谈大佬的视频播客 - Lenny’s Podcast - Peter Yang - AI and I（by Every） - Unsupervised Learning（by RedPoint Capital） - Training Data（by Sequoia Capital） - Minus One（by South Park Commons） - Google DeepMind: The Podcast - No Priors - AI+a16z - Latent Space - The AI Daily Brief - Lightcone Podcast（Y Combinator） - Lex Fridman - Dwarkesh Podcast 2. 大佬在活动 / 大会上演讲的录像 - YC Startup School - AI Engineers World Fair - Sequoia AI Ascent - Stripe Sessions - Figma Config 3. OpenAI / Anthropic 的官方频道 4. 手把手教你用 AI 工具的干货教程 - Riley Brown - Greg Isenberg - Ras Mic - Mckay Wrigley 5. Andrej Karpathy

#小红书 #张咋啦 #YouTube AI 频道 #AI 信息 #AI 工具

3周前

这几天忙成狗，早上通勤路上一口气把最近的 GPT-5 新闻刷了个遍，刷着刷着就觉得：这也太互联网了吧。乌泱泱地搞升级换模型，说能力更强、更智能，结果落地那一刻像极了高配空降干部接手老团队。履历一堆光环，一上来就要重构、提效。话听起来都对，就是没一句和你眼前的实际业务对得上。大概是这样：老流程被砍、老员工被裁、节奏被打乱，线上各种不稳定。最讽刺的是过不了多久，那些被优化掉的老人，又一个个被请回来擦屁股，只是换了个身份，问题还是他们兜底。这剧本是不是太眼熟了？空降新官 → 否定一切 → 系统崩了 → 老人回来 → 勉强稳住 → 继续讲故事。发生在 AI 身上的事儿，整套逻辑和节奏、锅的走向，全都跟我们在公司里经历过的一模一样。不一样的是这次的主角换成了 GPT。虽然荒诞，但剧本还是那个剧本。

#GPT-5 #AI #互联网 #裁员 #空降干部

3周前

纳米 AI 又双叒叕升级了。起初看到这个“多智能体蜂群”概念，我以为只是套了个新壳。毕竟这个行业讲“多智能体”“协作”这样的噱头已经太多了。但当我看到它真的跑完了 1000 步不中断的任务、用一句话生成一支 10 分钟史上最长的 AI 视频《一万和十万个地球》时（视频和创作过程在评论区，技术含量高到离谱，值得一看），我突然有种感觉，这可能是 L4 智能体第一次真正落地。花了点时间把底层结构拆了一圈，我确认这是一个值得每个 AI 架构师认真研究的系统设计：如何让多个智能体像一个协作团队一样配合。你可能对国产 AI 抱有某种刻板印象，但这一次纳米 AI 在设计思路和架构上比国外超前了不少，落地也更彻底。 1️⃣ 我们可能正在亲历 AI 智能体范式的一次代际跃迁。如果说L1 是 GPT 聊天助手（接口）、L2 是低代码工具流（流程）、L3 是推理型专家体（个体能力）。那么纳米 AI 的 L4 多智能体蜂群，则是第一次真正把“团队协作”这一人类物种优势，在 AI 世界中复制、结构化并跑通。它让多个智能体在自然语言环境下组成一个可以分工和沟通的执行网络，完成原本要靠多人多角色配合才能搞定的任务。这个结构，本质上是一个面向任务与组织目标的蜂群协作框架：不仅连接了智能体节点本身，更引入了角色关系、记忆通道、任务流动和状态管控的结构性设计，具备演化与拓扑能力。 2️⃣ 人类得以进化，除了学会使用工具，更因为组织协作。纳米AI这次的升级，将这种“组织结构”完成了一次智能体层的结构映射：多个推理型智能体能灵活拉群、多层嵌套，组成目标导向的协作团队，像蜂群一样围绕目标分工合作。和传统 prompt 编排或工具链整合最大的不同是：它除了让 AI 会执行步骤，还组建出了一个有调度逻辑和行为状态、能容错优化的 AI 团队。可以说这是“多智能体系统的组织化跃升”，也可以称之为智能体的社会化起点的一次尝试。 3️⃣ L4 的意义到底是什么？模型更大了？接了更多的工具？我认为都不是，最根本的价值在于工作方式改变了：人从工具的使用者变成了智能体团队的组建者与管理者。从写 prompt 的人，变成了设定目标、管理角色的那个角色。纳米 AI 的 Agent 除了技术更加精进之外，背后的另一个深层含义是一场“角色权力的重构”的变革： 📌 对个体而言：第一次让一个普通人拥有一个 AI 专家团队，从“能做”到“能交付”，能力被指数级放大； 📌 对产品而言：第一次把“智能体协作”从概念化 demo，转化为可规模落地的生产力引擎。特别是在视频创作、电商带货、内容营销等场景中已经形成显著的效率溢价。这也标志着两个更长期、结构性信号的到来： 📌 AI 产品的核心竞争力正在从“模型大小”转向“组织结构” 谁能让多个智能体配合好，高效地完成复杂的任务，谁就能赢得最终的生产力范式。这已经是管理能力之争了。 📌 个体与 AI 的关系正在被重新定义个人从用 AI，变成了带着 AI 团队一起达成目标的人，这个从 prompt 到 team 的跃迁，比任何提示词工程都更深远。 4️⃣ 技术层面最让我感兴趣的，是纳米AI把“蜂群协作框架”跑通了。区别于 lead agent + sub agent 的固定调度方式，它采用了更灵活的“多角色可变协作结构”：一个可以持续拉群扩展、同步共享记忆、并行异步执行任务的协作网络，不仅能跑完 1000 步任务、稳定消耗 2000 万 token，而且人可以随时插入调优，整个过程都有协作路径、执行角色和意图。解决了黑盒式生成的最大痛点——暗搓搓地跑完一堆未知的 chain。我现在脑子里浮现的是一个动态运行的“智能协作图谱”，像是从上帝视角看一个 AI 团队在干活。 5️⃣ 为什么这次升级值得格外关注？因为从全球范围看，“多智能体协作”仍然是 AI 系统设计中最难啃的骨头。 LangGraph、Autogen、CrewAI 都在做相关探索，但仍然停留在开发者初级阶段，很难完成真正产品化封装。相比之下，纳米AI是目前唯一把“蜂群协作框架”在平台级跑通并完成产品化上线的 AI 系统。从平台层级构建了可拉群、可嵌套、可多角色协同的智能体调度结构，具备连续推理、自主迭代、共享记忆和人机协作的复合能力，真正实现了从“AI 工具集合”向“AI 协作组织”的跃迁。这意味着，它第一次让“协作”成为智能体产品的基本构造单元，为整个行业开辟出一条新路径。数据也印证了它的行业地位： 📌 纳米 AI 是目前唯一连续数月稳居全球前五的国产产品之一，并长期高于 Perplexity、和国内其他大厂产品。 📌 AI 搜索市场呈“寡头效应”后，纳米 AI 长期占据国内第一，甚至以压倒性优势领先 Manus 九倍以上，确立了国内智能体流量龙头地位。 6️⃣ 所以，不要再用看“AI玩具”的眼光来看这个产品了。纳米AI的这次升级，代表的是一次从聊天式 AI到组织型 AI的质变。纳米 AI 帮我们组建一个更强的 AI 团队，我们也是时候改变一下自己的工作方式。那么问题来了：你准备好带一个多智能体蜂群团队工作了吗？ 7️⃣ 它的架构值得你拆一遍：蜂群协作+角色调度+共享记忆的 mesh 组织设计，可能会成为未来多智能体系统的设计基线，值得被更多团队借鉴。

#纳米AI #多智能体蜂群 #AI团队协作 #L4智能体 #组织型AI

1个月前

去年我第一次用 Copilot，有点小震撼，自动补全几行代码、写个工具脚本爽得不行，心想：“以后大家差不多了，AI一上，谁还不是个工程师？” 现在回头看，这想法有点天真了。真实情况是： AI 不但没抹平差距，反而把程序员之间的差距拉成了鸿沟。以前顶尖程序员和普通程序员差 10 倍，现在差的可能是 100 倍、1000 倍。为啥？因为 AI 直把普通程序员的短板暴露出来了。你以前靠写 for 循环、CRUD、接个接口混饭吃，AI 一上来，几秒写完。你价值直接被抹平。但那些平时就擅长拆系统、搞架构的程序员，AI 简直是为他们量身打造的外挂。特别是在 Cursor甚至 Claude Code加持下，给出更清晰意图，AI 秒写函数、重构模块，配合得像多年的搭子。关键是：你指令写得越准，反馈越强；你想不清楚，AI 也只能陪你绕圈。过去写代码是“想 1 写 9”，现在变成“想 9 写 1”。想不明白的，一样卡死；想得清楚的，效率爆炸。而且这不是简单一句学不学 prompt 的问题，是有没有那个“我知道这块应该用什么方法做”的系统建模能力。到底是写代码的，还是在设计系统的，在 AI 面前会无限放大。工具越来越聪明的时代，真正的差距只会转移到一个地方：一个人脑子里到底装了多少“不可替代的判断”。 AI 把“怎么做”给你代劳了，但“做什么 + 为什么这么做”那部分，只会更贵。

#AI 鸿沟 #程序员差距 #系统建模能力 #不可替代的判断 #AI 辅助编程

1个月前

《How to Fix Your Context》这篇上下文工程指南，建议跟 Manus 六大上下文工程法则一起看，它们分别来自两个方向：一个是跑在工程一线踩过坑的 Agent 系统实践者，一个是站在系统架构角度思考 LLM 工作方式的认知构建者。我把这两篇文章有一起读了一篇，有种“内功交叉灌顶”的感觉。作者回顾了长上下文为什么会失败？ 1️⃣ 上下文污染：当幻觉或其他错误进入上下文，并被反复引用时。 2️⃣ 上下文干扰：当上下文变得过长，以至于模型过度关注上下文，忽视了训练期间学到的内容。 3️⃣ 上下文混淆：当上下文中的多余信息被模型用来生成低质量的响应时。 4️⃣ 语境冲突：当你在语境中积累了与提示中的其他信息相冲突的新信息和工具时。回忆下是不是都是自己遇到的问题，作者给了一些解决的思路，有很多跟 manus 惊人的一致。 1️⃣ RAG：有选择地添加相关信息以帮助 LLM 生成更好的响应统一下认知，信息添加的底层逻辑一定不是查到了，而是查对了。作者强调 RAG 要有选择性的添加，而不是全部贴上；重点是围绕当前任务构建语义增强。 Manus 的做法是干脆放弃查入，把信息挂载在文件系统，留 path + 摘要 + 可调用工具。能明显感觉到 manus 对 token 成本的极致敏感🤭。我自己的实践中最常见的失败是，RAG 查得很准，但 LLM 输出完全无感，因为 context 本身没告诉它该往这个方向推理。RAG 本质是建模信息在认知链条中的地位，不重要的别查入，重要的也别硬塞，要设计成“知道在哪 + 能够调”。这跟这两篇文章的底层逻辑就高度一致，真正高质量的 RAG，不在检索，在策略。 2️⃣ 工具配置：仅选择相关的工具定义添加到您的上下文中作者提倡按需加载工具定义，而 Manus 的哲学是工具全集保持不变，用 mask 控制直接把权重干成负数。相比而言 Manus 的做法太巧妙了，可以说是对大模型底层原理应用的最佳实践了。如果你踩过“工具定义变了导致 cache miss + hallucination 增多”的坑，一定能彻底折服。但这两种方式解决的问题都高度一致，无非是你是靠 prompt 配置行为，还是靠 logits 控制行为？我理解只要你希望上下文命中率高、模型行为稳定，就必须构建一个“行为可变但结构不变”的系统。至于选择哪种，重点都在让模型以为它有哪些选择。 3️⃣ 上下文隔离：将上下文隔离在各自专用的线程中作者讲上下文隔离是为避免多任务混淆。Manus 虽然没有“线程”的抽象，但通过 append-only 的 context + 每轮状态复述 + 工具调用封装，其实完成了逻辑线程的构建。失败的上下文不要强行修复，而是重新创建一个上下文分支，把之前的 trace 作为引用历史保存下来。这点在实际开发中很关键，很多工程实践中都会出现“污染后还想继续用旧 context”的习惯，反而越补越乱。我现在更倾向于一旦感知幻觉或目标漂移，就把当前上下文 snapshot 掉，开一个 fresh context thread，哪怕代价是多一次调用，也比把幻觉当真实继续往前错更稳定。 4️⃣ 上下文修剪：从上下文中移除不相关或不需要的信息很多人以为修剪就是删“旧内容”，其实真正的 pruning，是删除“结构上已经失效的信息”。他们的“能 offload 的就 offload，不能 offload 的就摘要”。我也一度以为摘要是浪费时间，但后来发现一段带摘要的 context，远比一堆片段更有推理价值。尤其是在长任务执行中，摘要除了压缩信息，更多的是给大模型构造构造注意力锚点。我现在会把某些任务 summary 放在末尾，一方面压缩 token，另一方面也是引导模型聚焦。顺带一提，很多人会选择把失败信息也修剪掉，但其实保留失败的 trace 本身也是一种重要策略。Manus 的做法是把失败信息 offload 到外部 trace 文件中（参考6️⃣），再在后续回顾或 summary 阶段引用。这跟人学习有点像，错误是成本最大的训练材料，不应该被直接忘掉。补充个方法论：上下文修剪，千万不要认为目的是“省空间”，核心是要让每个 token 都承担“策略密度”。我们最终修建掉的是模型注意力的错位。 5️⃣ 上下文总结：将累积的上下文浓缩成一个简要的总结作者强调总结是为了更高效的行为生成。Manus 做得更极致，每一轮都复述当前目标 + 状态 + 期望动作，用自然语言重新激活注意力焦点。我实测过不复述 vs 复述的差别：前者行为漂移率接近 30%，后者几乎稳定在主任务路径上。你能感受到的是 LLM 的注意力其实是个滑动窗口，不持续提醒，很容易跑偏，这一点就跟我们管理一个想法很多的员工一个道理。说白了，总结不是让模型记住，而是让他去遗忘，终极目的是要做注意力的再分配。 6️⃣ 上下文卸载：将信息存储在 LLM 的上下文之外，通常通过一个存储和管理数据的工具来实现这一部分我必须单独点个赞，确实简单有力量，很多人不以为然：就把信息放到外面嘛，有什么大不了的？但真正在 Agent 系统里跑起来你才会发现：Context Offloading 是少数能从认知层面、工程层面、可扩展性层面都闭环的设计策略。作者在文中提到 Anthropic 的 “think” 工具，他们干的事儿就很朴素：给 Claude 搞了一个专用 scratchpad，让它在正式输出前可以先写一写、想一想。我们过去总觉得 scratchpad 是辅助产出，但 Anthropic 的设计更像是，让 Claude 在回答前自己反刍一下。 Manus 给出的做法本质也是一样的，只不过它没有叫 scratchpad，而是把这套行为模块化写进 agent 文件系统，每一个都是模型在任务过程中产生的“中间态”，不属于主 memory，但又比 response 更结构化。我们太容易陷入一个错觉，以为上下文是一个扔进去的信息堆，但其实真正有用的信息往往是过程中的状态，而不是最终的答案。但是这些状态恰恰是最不适合塞在主上下文里的，既容易冲淡主任务注意力，又会拖垮 token 成本。实际上验证下来，给 Agent 留出一块临时记忆区，效果极其稳定，特别是在多步骤长任务里，模型不担不会迷失，反而行为会越来越收敛。作者说得对，这东西简单到你不相信它有用。也许未来大模型的长记忆系统，真正的突破口不是在上下文窗口扩到多少 M，而是什么该存在主线程里，什么该写在 scratch 区。简单总结下：从“怎么放信息”到“怎么设计上下文作为系统运行时” 加上最近对 vibe coding 的观察和体验，我现在越来越确信：未来 AI 系统真正的代码，一定是你写给模型的上下文构建逻辑。这两篇文章，建议放进上下文工程必读清单。搞懂它们，搞 Agent 才算入门。

#上下文工程 #LLM #RAG #Agent系统 #上下文管理

1个月前

全球高压竞争下被动蔓延的一种工作文化副产物 996，被迫作为中国文化输出了，没什么值得骄傲的，更多只是硅谷创业者当下焦虑的一种侧写。 AI 创业显然已告别靠技术破局的理想阶段，开始拼速度、拼兑现、拼意志。人话就是：模型卷完卷数据，卷完数据卷人，只要还能在短期拉出差异化，哪怕牺牲睡眠、家庭、生活，那些愿意全身心献身的人，自然更容易成为被系统偏爱的那一群。我相信美国佬并没有对东方吃苦文化认同，只是在估值压力、交付节奏和地缘焦虑交织下，用极致投入换取有限确定性的集体妥协，哪怕这确定性本身就是靠着高强度压榨团队换来的，也比什么都抓不住要强。中国的 996，是制度惯性和等级秩序下的高压型内卷；而美式 996，则是自我神话与成功焦虑共谋下的主动透支。一个身不由己，一个是自我驱动，结果相似，逻辑全然不同。但这种形势最可怕的地方是，当越来越多人信了，不信的人连站在原地的权利都在被剥夺。国内互联网创业史那套压榨模板还没散场，加班即修行、燃烧才配成功这一套，已经在全球创业圈悄然落地 fork。我对这一切很悲观，当中美都卷起来的时候，这场看似热血、实则耗损的速度游戏，到底能冲出几个神话，又会留下多少一地鸡毛。

#996工作制 #中美内卷 #创业焦虑 #高压文化 #过劳

1个月前

老爷子的演讲让我顿悟了。原来人类本身就是个带幻觉的大语言模型，而 AI，是那个能共享幻觉、还能蒸馏成亿比特带宽的版本。 Hinton 在 WAIC 演讲，真的句句暴击： - 人类学知识学完就忘、死了就没，AI 直接多智能体同步、群体进化； - 你以为在训模型，实际是在养一只小虎崽； - 长大之后是救你还是吃你，全看你有没有教它“别反人类”。 “让 AI 聪明”和“让 AI 对人类好”，是两码事。这是技术问题吗？不是，是文明的事，是你是不是配当造物主的问题。背脊发凉又热血沸腾，一直以为自己在写 prompt，现在看我是在写神的说明书。

#AI #Hinton #大语言模型 #文明 #造物主

1个月前

很多技术博客看完就忘，但 Manus 的这篇上下文工程日志，却让我有一种很久没遇到的熟悉感，就像十几年前我第一次读《编程珠玑》时那种“结构清晰又内功深厚”的惊叹：用极简的语言，把系统最核心、最隐秘的痛点一层层拆出来，再用“实践炼过、成本试过、坑都踩过”的方式，给出一套优雅得近乎朴素的工程解法。把你从“github 上一堆看起来能跑”的原型，带到“可以抗住百万次交互”的真实世界。如果你正在构建 Agent 系统、研究 prompt 调度、RAG 链路、日志记录、踩过cache miss、上下文错乱、模型行为漂移等无数坑，那肯定非常能共鸣 Manus 的实用主义。很多时候知道问题在哪，但还没把它总结成一条法则；明明做了优化，但没能力从认知上总结它为什么成立；但没人告诉你：其实这些事，别人已经系统总结过了，而且优雅 100 倍。我读 Manus blog 的时候，就有这种踏实感，原来我们绕过的弯，爬过的坡是可以被结构化定义下来的。分享下我对 Manus 六大上下文工程法则的拆解，可以看作是“智能体上下文系统设计的六个底层约束”。 1️⃣法则一：围绕 KV-Cache 进行设计让智能体变快，不一定靠生成快，记忆前缀不重算也能加速。我们经常把注意力放在 LLM 的生成效果上，优化 prompt 内容、格式、语言风格。对于聊天机器人，输入和输出的长度通常比较均衡。但对于AI智能体，情况则大相径庭，智能体场景中最昂贵的成本其实发生在前置阶段：当一个智能体执行一次“读取上下文 + 推理 + 输出调用”的循环时，它的输出可能只有几十个 token，而输入上下文可能高达几千甚至上万 token，在这种严重失衡的输入输出结构下，预填充阶段的计算成本才是拖慢系统、放大延迟的罪魁祸首。如果你最近在做 multi-agent 系统，尤其是在“需要快速轮询”“低延迟交互”这些及时响应场景中，明显感到响应慢、链路卡顿、用户体验下降，那你极有可能踩在了这条隐藏的高成本区上，每个 Agent 都在重复预填整个上下文，导致系统性能雪崩。 Manus 的处理方式非常极致：把缓存命中率当作核心优化指标，哪怕为此牺牲 prompt 灵活性都在所不惜。 KV缓存是LLM的一项优化技术，它能缓存已经计算过的前缀（注意是前缀）的键值对，避免在后续请求中重复计算。为了最大化缓存命中率，Manus采取了以下实践：保持提示词前缀稳定：即使是单个token的改变也会使该位置之后的所有缓存失效。一个常见的错误是在系统提示的开头包含一个精确到秒的时间戳，这虽然能让模型知道当前时间，但却会彻底破坏缓存。确保上下文是 append-only：避免修改历史的动作或观察结果。同时，要保证序列化方式是确定的，例如，很多编程语言在序列化JSON对象时并不保证键（key）的顺序，这会悄无声息地破坏缓存。显式标记缓存断点：某些推理框架需要手动在上下文中插入缓存断点。在设置时，至少要确保系统提示的末尾是一个断点。 2️⃣法则二：掩码，而非移除随着智能体能力的增强，其可用的工具会越来越多。很多人一开始觉得工具是智能体的核心，一个自然的想法是动态地管理这个工具集，比如使用类似RAG的技术按需加载工具定义。就是把工具按需加载、动态切换、上下文中途插入，这听起来很动态、很模块化，但在真正跑起来之后，Manus 发现这是一个陷阱：在迭代中途动态增删工具会带来两大问题：缓存失效：工具定义通常位于上下文的前部，每次工具定义变化，都会导致后续所有步骤的KV缓存失效。模型困惑：当历史记录中引用了当前上下文中已不存在的工具时，模型会感到困惑，容易导致格式错误或幻觉出不存在的动作。你有没有遇到过越加工具模型越不稳定，生成经常“选错工具”“乱组参数”甚至出现没定义过的操作这样的幻觉，那你可能已经踩上这颗雷了。 Manus 的解法非常聪明也非常工程化：保持工具定义集稳定，转而使用“掩码”技术来约束模型的选择。通过在解码阶段利用logits处理器屏蔽（或强制选择）某些token，可以控制模型在当前状态下只能选择允许的工具，而无需修改上下文中的工具定义。例如，当用户刚输入新指令时，Manus会通过预填充特定的回复前缀来强制模型立即回复用户，而不是先执行某个工具。此外，他们还巧妙地为工具名称设计了统一的前缀，如所有浏览器相关的工具都以browser_开头，所有命令行工具都以shell_开头，这使得在特定状态下仅允许某一类工具变得非常容易 ()。这个设计的哲学很现代：不要试图让模型“理解你不想让它做什么”，你就直接不给它做的可能性。 3️⃣法则三：将文件系统作为上下文上下文不是无限堆料，而是构建随取即用的语义型记忆索引。即使模型给你 128K、1M 100M的上下文窗口，它也依然不够。你不知道哪个网页会突然给你塞个两万 token 的 HTML，你也拦不住哪个 API 会返回一个五层嵌套的 JSON，你更不知道用户什么时候发来个几十页的 PDF。这带来了三个大的问题：观察结果巨大：当智能体与网页、PDF等非结构化数据交互时，一次观察就可能轻易撑爆上下文窗口。性能下降：即使没有超出窗口限制，模型在处理超长上下文时，性能也往往会下降。不止拉高计算延迟、引入注意力混乱，还让模型迷失自我。成本高昂：即使有前缀缓存，开发者仍然需要为传输和预填充每一个token付费。 Manus 的做法有很强的借鉴意义，它做的不是扩容，而是外置。他们把文件系统当作一个无限持久化的“语义型存储空间”，它具有三大优势：大小无限、本质上持久、并且可由智能体直接操作。模型在上下文里记录路径、摘要、索引，真正需要的时候再调用读文件这个工具。这种方法还支持可恢复的压缩策略：即使一个网页的详细内容因为上下文空间不足而被丢弃，它的URL或文件路径依然会保留在上下文中，智能体可以在需要时重新访问它。这其实是 Agent 系统中一个很高级的认知结构：不是把所有信息喂给模型，而是训练模型具备“知道信息在哪”的能力。 4️⃣法则四：通过复述操控注意力跟我们日常复盘碎碎念一样，Agent 执行过程中的目标也不是记住的，而是每一步都重新提醒一下自己。在我自己做 Agent 系统的时候，经常发现一个现象：模型走着走着就忘了它原本想做的事，偏离目标、越绕越远。我们管这个叫“迷失在中间”，但在工程语境里，这种“目标漂移”其实是上下文 attention weight 的失焦问题。 Manus 的解法很朴，每轮都更新一次目标和当前状态，然后把这个文件的内容贴到上下文最后。看起来像是个复读机，但背后其实是一种“语义注意力偏置”：这个行为相当于智能体在不断地向自己复读它的总体目标和当前计划。由于LLM的注意力机制倾向于更关注上下文末尾的近期信息，这种复读有效地将全局计划推入模型的近期注意力范围，从而利用自然语言本身来偏置模型的注意力，使其始终聚焦于核心任务目标，而无需对模型架构进行任何特殊修改。我感觉这个方式特别美，因为它没有引入任何额外结构，但却做到了最接近人类不断自我提醒的认知行为。 5️⃣法则五：保留错误的内容一句话：失败是智能体推理链上的必要节点，在大任务的执行过程中，失败是常态。几乎所有 Agent 系统都会有 retry 机制：出错就重来，格式错就重置。很多人为了“干净”，在智能体犯错时直接清缓存、重试调用，结果模型变成一个永远不长记性的工具轮回者。它永远不知道自己错在哪，也就永远学不会避开这个坑。它今天格式错一次，明天还错一样，明明是上一步才失败过的函数，它下轮又敢信心满满去调用。 Manus 的做法是反常规的，他们选择保留所有出错信息：失败调用、错误观察、甚至栈追踪，一条不删，照样放进上下文里。有了这些证据，模型就能在后续的推理中隐式地更新其内部的信念模型，从而调整其行为的先验概率，降低在相似情境下重复犯错的可能性。这种吃一堑长一智的做法，让模型记住自己干砸过，在未来的语义决策中，自动规避相似路径。这种让模型知道这条路不通的方式，比任何显式标注更接近认知建模。所以，如果你发现 Agent 一直“重复同样的蠢事”，那就别再清上下文了，错是它的，但学会是你的责任。 6️⃣法则六：不要被少样本示例所困你在构建提示词模板时，是不是喜欢封装成一串标准化样例？确实能跑得通。few-shot prompting 在很多任务中非常好用，但在多轮、动态任务中，如果你给的示例太相似、结构太固定，模型很容易陷入“模式依赖”，变成“照搬机器”。当你发现模型开始照猫画虎地生成、总在学你给的那个格式、甚至一字不差地模仿之前的样例的时候，就要开始思考如何构建样例，让模型的行为多样分布。 few-shot 用得太像 few-clone，会让模型陷入“格式安全区”，变成行动保守者，而不是策略探索者。 Manus 的做法是刻意制造结构化变体，在智能体的动作和观察中，有意识地引入少量但结构化的变体，给的示例语义一致但表达方式不同。通过打破一成不变的模式，有效地使模型的注意力多样化，避免其陷入单调的模仿循环，从而提高其鲁棒性和适应性。这个策略的高明之处在于你让模型理解还有别的方式也可以对。最后 Manus 这篇小而硬的博客，像是你走了很远很远之后突然在半山腰看到的一块坐标石碑，告诉你你快进入上下文工程师的区域了。做得越深，就越知道所谓“智能体跑不起来”，是根本没给模型构造一个可持续运行的信息生命系统，它记不清目标、摸不清状态、想不清下一步能干嘛，更不用说从失败中自我修正。对我来说，这篇文章让我确认了我们走的那些弯路其实早有共性路径，也让我第一次能用一套更准确的语言来描述我眼里“一个靠谱的 Agent 系统到底需要什么样的上下文架构”。只要你干过这些，你就会意识到：Prompt 是告诉模型你想要什么，Context是构建一个系统，让模型每一次都有机会自动靠近正确。如果你正在做 Agent，或者计划进入这个方向，不妨用这六条 checklist 把你现在的系统过一遍：哪个上下文会频繁变动？哪个状态是隐式的？错误有没有暴露给模型？工具调用是否具备 mask 控制能力？你的记忆系统是全塞还是挂载的？

#技术博客 #上下文工程 #编程珠玑 #系统痛点 #工程解法

1个月前

Cursor 的 know-how 落在程序员身上，批量买 token、打磨 IDE 场景、绑定开发者，构成第一波模型变现路径。为什么 aicoding 会先火？一是代码高度标准化，容易被模型吃下；二是程序员本身就是身在局中的 know-how 产出者，懂工具也懂场景。但这套逻辑不会止步于开发者。下一轮，一定会卷向各大垂直行业：医生、律师、分析师、质检员…… 谁能把行业语言、业务流程、结果反馈封装成一套智能体体系，谁就能在行业内定义下一代 AI 。过去十几年是互联网+，这几年是AI+，而真正可能颠覆产业范式的，恐怕是Agent+。还记得前段时间红杉闭门会上“AI 不再是能力工具，而必须成为交付结果的系统”的核心判断转向。行业内一定不再是工具附加智能，而是角色被智能替代。Agent+ 的本质，是把 token 打包进懂行业的产品力里。 AI Coding 只是序章，当程序员的生产力被 AI 数百倍地激活之后，真正的大变革，将在每一个垂类入口等待被唤醒。而未来的 AI 战场，一定属于那些跨界的人：既懂技术，又深耕行业；既能对接智能，也能驾驭流程。也许你正好是其中之一。

#aicoding #程序员 #模型变现 #垂直行业 #know-how

1个月前

AI Coding 圈最近真的太热闹了。 Claude Code 的两位产品经理，Boris Cherny 和 Cat Wu，在 Cursor 稍作停留便双双回归。腹黑一把，给这出戏取个名字：《如何用两位PM换来一次竞品调研》。行业里一般有两种玩法：第一种玩法：送人过去，看看竞品怎么玩。第二种玩法：反着来，把竞对核心人挖出来，顺便把知识副本一并拷走。无论哪种玩法，都不太体面。这次可能是第一种，行业经典剧本之一：送一枚人形 API 到竞对内部调试下。两周时间足够完成一场定向式知识抽取了。最惨的可能是 Cursor：人还没来得及用好，转头就把情报原封不动送回 Claude 总部了。这回头的箭搭弓搭的有点快了。 Claude Code 应该没事，甚至可能更清楚该怎么做了，可以铺更大的 IDE 版图；Cursor 就难说了，可能得抓紧开个内部 review，问问哪些核心想法是不是已经“不小心流出”了。不知道是不是还得装作风轻云淡。

#AI Coding #Claude Code #Cursor #竞品调研 #人才流动

1个月前

挺好的一本书，没想到竟然能把 Agent 做得这么细、这么落地。建议收藏，常看常新。阿里云这份《金融行业 Agent 百景图》真的太全太实了，把过去一年在银行、证券、保险里做的大模型落地实践梳理成册，200 多个 Agent 案例，干货密度超高。比如智能投研怎么跑，客服怎么加 AI，风控怎么做合规验证，甚至连监管辅助 Agent 都写出来了；全程围绕 MoA（Mixture of Agents）+ RAG 架构，搭配工具链 + 多模态，完全就是一本金融 AI 工程化说明书。如果你是已经在做金融 AI 的，看这个能找到方向参考；如果你是对金融感兴趣、但不知道 AI 能干嘛、或者 Agent 怎么落地的，这份可以直接抄，照着做都行。哪怕你是其他行业，只要在想“我这行业 AI Agent 能干嘛”，这份也能提供非常多可迁移的思路，值得好好读一遍。电子版链接放评论区，建议收藏一份，做 AI 的别错过，做金融的更得看。

1个月前

吴恩达上个月在 YC 的闭门分享，我最大的感受是：这是为“想真做事”的人准备的系统性认知地图。很多人聊 AI，是在讲技术趋势、AGI、终局预言；他聊的，是从第一个 idea 到第一个用户，再到第一个能复用的系统，怎么能更快、更准、更责任地走一遍。以下是拆解后的核心洞察，给所有搞 AI 创业、想用 AI 干点事的人👇 1️⃣ 执行速度是核心变量，胜过一切幻想 “模糊想法=烧钱，具体方案=印钞”。具体到什么程度？得是 engineer 听完马上能动手写代码的那种。执行速度不是要你瞎跑，而是能快速把创意变成原型，再用实际反馈把想法打磨成产品。你能跑多快，不在于有多聪明，更重要的是能不能把构想具体化、把验证节奏压缩成小时级。 2️⃣ 智能体是认知流程的重写，不是 API 套壳很多人把 Agent 当“插件化 prompt 多轮调用”。但吴恩达讲得更深：Agent 是让 AI 模拟“非线性思考”的结构单位，就像人写文章要列提纲、查资料、反复修改。 agent workflow 的本质，是让 AI 从一次性输出变成演化式构建，从 stateless prompt → 有记忆、能反思、能协作的工作单元。也就是谁能把业务流程转化为 Agent 结构，谁就能定义新的系统边界。 3️⃣ AI 编程 ≠ 会写代码，而是表达意图的能力吴恩达说，现在的编程能力，是“新型表达力”。未来的 core skill 是：清晰表达你要什么、组合不同 AI 模块拼出解决方案、具备足够技术判断力，知道什么该微调，什么该 prompt。这就需要跨领域的人才，越是跨领域、越能思考并表达出来新的产品。 AI-native 编程，前期阶段先不要追求完美代码，目标先盯着构建一个可快速被重写、被验证、被迭代的系统。 4️⃣ 技术架构正在从“单向门”变成“可撤回式决策” 以前选错技术栈 = 半年白干；现在选错，可能下周就能重构。工程并没有降智化，核心要点其实是开发成本下降，试错频率提升，组织必须学会“快速判断 + 快速反悔”。判断力比之前要求更高，更新频率从月级变成了日级。技术决策也正在重构，从“赌一个方向”变成“构建一个可快速验证、快速回滚的闭环”。 5️⃣ 产品反馈成了瓶颈，PM 要摆脱协调者，自我进化成为节奏设计者随着工程效率提升 10 倍，最大限制变成：做什么功能？用户要不要？怎么收反馈够快够准？吴恩达说他见过 PM 和工程师比例 2:1 的配置——这不是反常，而是现实。未来的组织优化，对于程序员的需求其实是在减少的，不再需要更多人写代码，提高组织获取用户信号的速度变成了首要。 6️⃣ 创业成功，一定是代表着你比别人早半年找到对的方向 “能不能做”不是问题，“值不值得做”才是关键。AI 让做东西变快了，但也让“做错方向”的成本变高了，因为每错一步都放大后续资源浪费。所以他强调一个核心机制：构建快速验证的原型机制 + 多渠道信号源 + 直觉更新系统。你能更新得多快，你就能决策得多准。 7️⃣ 最后，AGI 和“AI 威胁”不是你现在该焦虑的吴恩达对炒 AGI、妖魔化 AI 安全的风气很警惕。他讲得很清楚：真正的风险，不是 AI 太强，而是滥用权力 + 封闭生态；真正该做的，是负责任地使用 + 开放共享技术红利。封闭平台 + 安全话术 = 技术垄断的护盾；开源 + 多元协作，才是 AI 创新的护城河。最后的最后，总结一下：这场闭门分享没有预测未来 AI 能多牛，吴恩达明明白白的告诉你现在能怎么用 AI 把事情干起来的战略地图。他讲得很现实，AI 会加速一切，包括失败。执行速度是核心变量，判断力是护城河，反馈回路是竞争力。你不需要 all-in AGI，但你得学会怎么拼出属于你的那套 agent 乐高。如果你也在构建 AI 产品、agent 工作流，或者尝试用 AI 重写业务系统，建议把吴恩达这场演讲当作创业者操作系统升级的读本。技术潮水会一直往前涌，但真正能穿越周期的，只有一个问题：你是不是真的比别人更快做出来、更快做对、更快做成。

1个月前

面了几个特别不错的人，尤其是在 AI 项目上真的是“能打”的类型，手上有东西，落地经验也扎实。结果呢？卡在必须得是本科。真的是一边生气一边困惑，都2025年了，还在拿本科线当护城河？ AI 这个行业，说白了，已经不是传统“学历即能力”的时代了。真正能推动项目的人，很多是靠自学、自跑、自调起来的，甚至有些野路子出身的，比你想象得还专业。但现在的问题是，哪怕你是业务 leader，想招这种人，流程就死在那道线里。真·制度自废武功。所以就变成一个荒谬的现实：我们嘴上说着“人才最重要”，实际操作却是先用学历一刀砍掉 80%。整个组织对“什么是合格人才”的定义还停在工业时代，但现在是AI时代了啊，你得用新的标尺。否则，结果就是干活的人进不来，会说话的人混得开，项目落不了地，还得回头怪人不行。

1个月前

微信支付终于还是上了 MCP，现在体验版在“元器”里可用，这次真把“AI 能不能赚钱”这个老大难问题，抡出个实质性解法了。利好一大片。之前所有藏在微信后面用 AI 机器人做私域运营的，提示词调来调去，最后发现最大的问题居然是：钱怎么收。尝试过跳链接？塞二维码？推小程序？全都割裂得不行，一到付费这步，用户就漏光了，转化细得像针眼一样。这次支付 MCP直接在上下文里就能自然地完成下单、支付，流程跟对话是连在一起的，说着说着，直接拉起微信支付就把钱给付出去了。就好像你跟 AI 聊天聊着，它说“我能帮你做这个，点这里”，你一点，它就开始干活了，完事还能自动验单。体验非常顺，链路短的惊人。这事最大的看点其实不在支付本身，本质上是对AI 时代的交易协议的一次尝试，让 agent 有了商业意识。Agent 除了提供服务，竟然真的能自己发起交易、验证交易、完成交付。这个能力，一旦跑顺了，微信生态 AI 生态要爆。而微信之所以能干，是因为它手上真的握着交易闭环这根水龙头。微信支付 MCP 这个能力，哪家能第一个跑出一批赚钱的智能体，真的就能来一大波热度，不论是营收上还是资本市场上。真的，在微信生态内，AI 活得像越来越像个个体户了。

1个月前

这种事历史上已经演过好几轮了。排字工被 DTP 干掉了吗？确实，但后来冒出一堆平面设计师、UI 设计师；会计被 Excel 自动化了吗？底层记账工没了，但财务分析、数据建模的岗位更多了。看清楚没？每一轮“被替代论”之后，留下来的从来不是老工种，而是新技能。现在的 AI 也一样重复工作会被模型包圆，但会提问、会拆问题、会 orchestrate agent 的人，才是下一个 10 年最吃香的技术人。换句话说：不是“程序员会被取代”，而是“还停在过去写法的程序员，正在被 AI 驱动的新一代程序员取代”。升级还是被淘汰，就看站在哪一边了。

#AI浪潮：重塑就业，风险暗涌？· 94 条信息

1个月前

在 AI Coding 火热的今天，几乎所有技术团队都在找路径：是加快平台建设、让 AI 更快进产线，还是深耕 prompt 工程、提高协作效率？不少公司已经开始立项目、定指标、搞培训，整个行业进入了“推动期”。我们公司也不例外。战略层坚定认为这是方向，也确实给予了明确的资源倾斜；团队层积极响应，平台搭建迅速、流程推进有序，整体看起来一片欣欣向荣。但在一线的实际使用中，问题也在快速暴露：尤其是在老代码体系中，AI 的接入效果并不理想，历史逻辑复杂、结构混乱、上下文缺失，导致 AI 很难真正帮上忙，甚至可能引入额外不确定性。更现实的是，大多数人并非在推动新项目，而是日复一日与既有系统打交道。在缺乏针对“存量屎山”的方法论支撑下，AI Coding 很容易变成“新流程套在旧系统”，流程先进，但与老逻辑严重脱节。目前的“团队配合度”，更多还是对战略方向的响应，甚至可以说是对管理意志的迎合。但在落地层面，仍缺少真正能跑起来的闭环机制：像 context7 之类的 MCP 等工具虽然频繁被提及，但在实际项目中能否支撑起稳定协作？prompt 怎么组织、输出如何校验、代码如何接入和反馈？这些基本机制还未沉淀下来，用一用可以，长期稳定很难。往下走，问题就不只是工具和平台，而是更本质的反思：到底什么才是“AI 原生的 Coding”？我们今天的开发模式、工程组织方式，是否已经不适合 AI 参与协作？如果还在用传统的开发范式来“喂 AI”，那 AI Coding 很难真正释放生产力，只会成为一层外挂、甚至负担。这对整个软件工程体系，是一次结构性挑战；而对团队协作本身，同样是巨大的挑战： AI 能力的介入，正在打破原有的任务划分方式、代码 ownership、沟通链路甚至审查机制。过去是“谁写谁维护”，现在可能变成“AI 写、人审、人补”，角色边界变模糊，协作机制还没重建。不重新定义协作方式、共识机制和责任边界，就很难真正让团队稳定地跑起来。所以，现阶段更需要的，不是更快的推动，而是一次更系统的重构：把 AI Coding 从“技术方向”拉回到“流程设计”、“协作模式”和“组织能力建设”上，形成真正可落地、可演进的机制。方向是对的，但路径必须让人能走。不知道你们公司现在是什么情况？有没有类似的感受？

2个月前

体验了一天 Gemini CLI，也刷了很多人的用法，先声明，我没有拿它写一行代码。但就是因为没写代码，我反而看得更清楚：这压根不是一个开发工具，而是一场关于“AI 操作系统”形态的预演。也是我为啥说“Google 难得让自己的作品走出浏览器”，ta 有自己的考虑。 Google 用一种非常低调，甚至有点刻意“只面向技术宅”的方式，把它对未来的构想——“让自然语言成为操作系统的主入口”，悄悄塞进了命令行窗口里，让你在不知不觉中体验了一次“语言即操作”的完整链路。它当然能写代码，甚至可以说这是它门槛最低、演示效果最好的一部分，所以很多人第一反应是拿它去和 Claude Code 比；但说实话，那只是皮毛。真正让我“咯噔”一下的，是它一句话就能搜最新网页、批量整理本地文件和照片、把一堆静态图直接转成小视频。过去你得开五个 tab、切三个工具才能做完的事，现在终端里一口气全打包，像是有个全栈多媒体实习生住进电脑，而且根本不用你教他命令。但问题也来了，现实门槛摆在那儿，CLI 的交互方式还没对上大众。我们这批人觉得好用，是因为我们会用命令行，知道怎么找路径、写 prompt、调环境。一旦离开这批人，CLI 对大多数用户来说，依然是巨大的门槛。别说 prompt 优化了，连“怎么打开终端”都能劝退大半。我很确认的一点，这玩意就是一次技术力的试水。 Google 先把系统级 AI 能力暴露给最早那批能玩得转的人，交给他们去试、去玩、去验证。真正要跑起来的，一定不是 CLI，而是那些被 UI 包装好的形态，Chrome 侧边栏、Workspace 浮窗、Android 桌面助手……到那个时候，Gemini CLI 里的这些“超能力”，才会真正进入大众视野。到时候，你不会再看到命令行，只会看到一个按钮，一个提示框，一个帮我搞定的入口。这才是 Google 真正要做的事：让 prompt 成为操作系统的一层，隐入日常、不再显眼。不要被 CLI 的形态迷惑，它不是终点，也不是主角。我最期待的是，当语言取代 GUI 成为系统 API，当交互方式不再是鼠标+窗口，那谁来定义这个“语义层”，谁就重新定义了未来的界面、工具，甚至我们的工作方式。开源的 Gemini CLI 是 Google 这个更大野心的起点。

谷歌Deep Research：AI操作系统雏形？· 55 条信息

#Gemini CLI #AI 操作系统 #自然语言交互 #Google #技术试水

2个月前

Gemini 2.5 Pro 发布好几周了，技术的底裤都被扒得稀烂了，报告才姗姗来迟。我看完技术报告，几件事值得聊聊。 1️⃣现在大家都喜欢玩矩阵，模型发布也不例外 G哥也不免俗，精心设计了一套产品矩阵，满足不同场景的需求，不展开了，就是想先吐槽一下。 2️⃣Gemini 能力在 G 哥家底的支撑下开始快速跃迁 Gemini 2.5 家族之所以能够展现出前所未有的能力，我觉得核心在于 Google DeepMind 在模型架构、训练方法和硬件基础设施上的一系列协同创新。一次完整的AI 作为系统工程的演化，着实精彩，很久没从大模型的技术报告里感受到如此的畅快淋漓了。 MoE 架构带来稀疏激活下的巨大模型容量，TPUv5p 提供算力基础，而 RL*F 后训练与思考机制让这些底层潜力被转化为真正对用户有价值的能力释放。一起来看下这套组合拳的关键点： 1. MoE + TPUv5p + RL*F + AI 批评家除了大家熟悉的 MoE 架构和自家硬件 TPUv5p，Google 提出了一个新的训练阶段策略——RL*F（Reinforcement Learning from AI Feedback）。最大亮点是引入“AI Critic”角色，由 AI 自我反思、提出改进建议，进一步增强答案质量，这点也是随着模型能力增强自然而然演化出来的一个方案，在做智能体的时候值得学习。 2. 思考模型依旧是大卖点现在谁都说有 thinking，我现在看到 thinking 跟电梯广告似的，严重过敏。但 thinking 确确实实改变了 AI 生成的节奏：先理解，再规划，再生成。 3. 思考预算是 AI 走向服务化的关键机制 AI 的推理能力终于可以计价了。以前模型的聪明程度是内建的，现在是你愿意花多少钱让它多想几步。这带来了更细颗粒度、更有 ROI 意识的 AI 使用模式。我预计在接下来一段时间内会一直存在的一个解决方案，根据任务复杂度动态增加思考深度。 AI 应用怎么做到能力可控、成本可控着实得认真学习一下，这也是 prompt 工程的一部分了，所以 Prompt 还是很重要，致敬李彦宏。 4. MoE 架构是思考机制可落地的核心 Google 勇于扯下遮羞布，我就是MoE。如果在一个稠密模型上跑几十轮思考，每轮都全参数激活，那成本是灾难性的。但 MoE 架构只激活一小部分专家网络，让深度推理的边际成本变得可控，这也是 Google 敢免费、敢降价的底气。这一整套机制下来，打通了算力、架构、训练策略和行为能力的完整链路。所以如果你是工程出身，应该会感到异常兴奋。 3️⃣三大能力融合，正在重塑 AI 的边界 Gemini 2.5 的突破并不体现在单点性能，而在于能力协同后的系统能力跃迁。这三点其实大家都知道了： 1. 超长上下文：模型从金鱼缸升级成汪洋大海了早期大模型像一只生活在金鱼缸里的金鱼，这个窗口直接推到百万级，实验中甚至达到了 200 万 tokens。但报告也坦率承认：有长上下文 ≠ 会用长上下文。它里面说了个例子：“宝可梦”和“巨石谜题”，案例非常关键：信息检索很强：能从 46 分钟视频中找出只出现 1 秒的事件；能用工具解开迷宫谜题。然而，在需要进行长期的、多步骤的生成式推理时，模型暴露了局限性。当上下文历史记录显著超长后，开始出现重复之前行为的倾向，陷入循环，难以维持长期的任务一致性。揭示了这个长期存在的问题：检索长上下文中的信息，与能够有效地利用长上下文进行持续的、创造性的规划和行动，是两种不同层级的挑战。前者好比在巨大的图书馆里找到一本书，而后者则好比读完图书馆里所有的书后写一部新的鸿篇巨著。但Gemini 2.5 在长上下文处理上依然取得了业界领先的性能。 2. 原生多模态如果上下文窗口解决了 AI 的“记忆广度”，那么多模态就是打开它的“感官维度”。 Gemini 2.5 全部支持原生多模态了，视频生成交互式应用、视频生成动画、音频网友们估计都玩烂了。我想提下音频能力的演进。在音频方面，Gemini 2.5 也完成了从单向理解到双向交互的闭环。Gemini 1.5 已经具备了强大的音频理解能力，可以对音频文件进行转录、翻译、摘要和问答。Gemini 2.5 则在此基础上，重点训练了音频生成能力，包括高质量的文本到语音（Text-to-Speech, TTS）和原生的对话式音频输出。模型能够实现低延迟的流式对话，让交互体验更自然、更流畅。更重要的是，它能结合思考能力、情感理解和工具使用，在对话中理解并回应用户的语气，甚至忽略背景噪音的干扰，使人机语音交互向着更接近真人交流的方向迈进了一大步。值得一提的是 Gemini 2.5 预览版 TTS 可以生成多位说话者的语音，跟 NotebookLM 一样可以创建播客。 4. 智能体能力 Google 给出了三个非常关键的智能体范式： Deep Research、Gemini Plays Pokémon、Project Astra，从被动回答，到主动执行，再到能实时理解现实世界并行动，这就是智能体的演化路径。 4️⃣不光 demo 牛，benchmark 也硬刚这部分不展开聊了，现在对 SOTA 有点脱敏了，一句话：很厉害，也很分化。 Aider Polyglot（多语言真实代码编辑）：82.2%，大幅领先 GPT-4o（30.7%）。 GPQA（研究生级问）：在 Diamond 难度下拿到 86.4%，远超 GPT-4.5（71.4%），推理能力很猛。 MMMU（跨学科多模态理解）：得分 84%，比 GPT-4o 高 15 个点，展示了多模态优势。 Video-MME（视频理解能力）：SOTA 成绩 84.8%，稳稳领先 GPT 系列。最后呼应一下开头，你能看到，不是一个靠调教出来的聪明模型，而是 Google 把 AI 当成系统工程在做：有基础设施协同（TPU、MoE）；有思维机制框架（RL*F + 思考预算）；有场景能力突破（长上下文、多模态、Agent）；有实际 benchmark 背书（开发、推理、感知全面领先）； Google 正在告诉我们：下一代 AI，一定能被构建、能被调用、能被服务化的，这篇报告给圈子里打了个样，这才是 AI 从大脑到体系的进化，这才是 AI 该有的样子。我 G 哥威武。

Google Gemini 2.5发布引发AI模型性价比热议· 141 条信息

OpenAI新德里发布会：ChatGPT语音翻译功能引发热议· 387 条信息

#Gemini2.5Pro #技术报告 #产品矩阵 #谷歌 #人工智能

2个月前

看到老罗微博，特意去翻了下数字人直播视频，有点意外。技术那套都能想象到，台本自动生成、动作执行上万次、语音语气高度拟人。但真正让我觉得惊讶的，是直播过程居然有“老罗感”，嘴碎、调侃、还带点莫名其妙的真诚，全挂在脸上。百度这次下手挺准，这场直播，更像百度扛着技术打了一次人设战，传说中的领先一个段位的数字人技术。就是不知道是不是 PPT 级别的作品。我反而没那么关注技术细节。如果技术是真的，以前说 IP 变现靠人设，现在人设可以直接写进模型里跑了。我在意的是一个问题：如果 IP 真能被这样放大，那这个行业的重心，会不会从谁来直播变成谁能被复制。不知道百度在数字人上的敲门声，是响在了当下，还是响在了未来那头。

#老罗 #数字人 #直播 #百度 #技术 #人工智能

2个月前

读完 Anthropic 的多智能体系统文章，有几个点挺触动的，尤其是放回我们平时在做 agent 编排和系统落地的过程中，对应起来很多痛点被他们提前踩过、总结得非常系统。这套系统看上去是给 Claude 提升复杂研究任务能力，底层其实是三个关键词：带宽、结构、机制。 1️⃣从 token 到带宽：扩容问题其实是系统问题他们很明确地说，单个 agent 很快就会遇到 token 限制，这不是模型能力不行，而是容量不够。很多时候 LLM 的“不会”、“忘了”、“答不出来”，只是 context 塞不下。这一点在我们自己调长链条、多跳调用的时候也很明显。Anthropic 选择的解法不是扩模型，而是拆任务、开并发、分 agent，每个 agent 自带上下文窗口，从系统结构层面扩容。这种设计非常实用，因为它绕过了 token 墙的天然限制，通过多 agent 并发变相把 token 维度拉开了。这是我最近做 agent 编排时反复体会到的：不是把 prompt 写得多聪明就能解决，而是要想清楚结构怎么设计，谁来拉信息、谁来拼结构、谁来追引用。 2️⃣提示词是系统指令，很重要、很重要、很重要！这篇文章有个细节写得特别清楚：主 agent 的提示词，是负责分配任务、指明目标、交代格式、选工具的。这个逻辑其实是我们做复杂 agent 系统中很容易忽略的一块：提示词不只是沟通语言，更是调度逻辑、任务协议、格式规范的集中承载体。尤其是多个 agent 并行运行时，如果没有一个清晰、格式化、结构稳固的 prompt 模板，每个子 agent 拉回来的信息会特别散、错漏率高、很难合并。这时候，主 agent 的提示词就等于一个调度中枢的“编程语言”。从我们平时用的实践来看，这就意味着主 agent 的提示词策略应该和流程图一样严谨：每一步要预设结果、预设失败、预设上下游。这块我觉得是现阶段很多 agent 框架还不够成熟的地方。 3️⃣系统级机制，决定了能不能撑进生产环境我觉得特别值得借鉴的工程概念：checkpoint、异步重试机制、全链路 tracing、彩虹部署。这几个在大数据异步系统里很常见概念，AI 领域得好好学习下。这些词不是为了好听，它们背后都是在回答一个问题：这个系统崩了怎么办？agent 卡死怎么办？升级逻辑还没验证好怎么办？一整套机制让这个系统不是在 demo 一个可能性，而是在上线跑任务、自动修复、平滑演进。平时我们在做流程型 AI 系统的时候，很容易只关注“怎么生成”“怎么判断好坏”，但 Anthropic 的做法提醒我：agent 系统本质上要往服务化方向走，就必须预设失败是常态，重试是能力。 4️⃣评估机制是不可缺的闭环，不然做不出反馈导向的系统进化他们有一个细节很打动我：让另一个 LLM 去评审 agent 的结果，从准确性、引用合理性、覆盖度等多个维度打分。这就相当于在系统里内嵌了 QA 流程，而且不是事后人评，而是可以插入调试链路的 LLM 评测器。我们自己在调多 agent 结构时常遇到一个问题：任务执行完了，但结果质量很难量化，只能靠人工判断或者事后比对。这套“LLM 评估 LLM”的机制，让我们开始可以想象一种更自动化的 agent 演化路径：系统自己跑，自己打分，自己选择 prompt A 还是 B，更适合持续调优。 5️⃣并发是工具，不是策略，适用场景边界要想清楚这套系统最适合的场景是：问题复杂度高、信息广度要求强、非实时产出型任务。例如政策研判、产品调研、文献综述、竞品分析这些，在私域服务里也可以类比成“多维标签用户意图研判”这种复杂工作。但如果放在需要紧密配合、频繁迭代、低延迟要求的任务上，例如代码生成、对话任务、实时接口构建，多 agent 的协调成本反而可能放大系统复杂度。所以并发结构是个好工具，但什么时候该开几个 agent，什么时候该单线程跑到头，这种策略边界要想清楚。这篇文章最核心的不是“我们做了一个多 agent 系统”，而是他们已经把多 agent 作为一种工程能力进行制度化建设：有流程、有容错、有评估、有上线机制。对在第一线实际落地 AI 能力的团队来说，有一个非常直接的启发是：构建 agent 系统，不能只是对话式的 prompt 编排，而要像搭服务一样，从任务定义到评估反馈，从并发机制到异常兜底，形成一整套可以持续运行的系统逻辑。这一点，比起模型调优，本质上更像是一种架构能力的竞争。

#多智能体之争：Anthropic生态VS单智能体· 21 条信息

#Anthropic #多智能体系统 #Claude #复杂研究任务 #系统落地 #带宽 #结构 #机制

2个月前

推荐个好东西：火山引擎的 PromptPilot。之前看 Google 的提示词白皮书，有个点让我印象很深：他们直接用 Google Doc 管理 prompt，写任务、版本、评估效果。那时候我就在想，有没有人真把这事儿做成一套完整系统？现在看到火山这套，有点意思了。它不只是“帮你写好提示词”，而是把这事儿当作工程问题来解的。最打动我的，是它在 prompt 优化这件事上做得极其系统，甚至有点狠。 ✅ 从任务出发构造 prompt（带结构、带变量、不是拍脑袋） ✅ 每一版 prompt 都挂着独立评测集 + 自动评分机制 ✅ 没有理想答案也能比对打分（GSB 模式） ✅ 每轮迭代都能 trace 效果，版本可控、可回溯我们之前做客服对话调 prompt，最常见的就是“改了一句，但说不上来到底有没有变好”。很多时候上线的版本其实就是“看着还行就先上”。现在它是：“打一套样本集，系统直接帮你跑出哪一版效果稳定”。我一直坚持：模型越强，对 prompt 的要求只会更高。尤其是在多轮任务、复杂场景里，prompt 不只是“写得好”，而是“是否可控、可管理、可进化”。 PromptPilot 解决的，是这个底层问题。它不仅能让 prompt 生出来，更重要是——能持续改下去。版本有 trace，样本能评分，逻辑能反推，工具还能外接，整个就是“prompt 的 AutoML + GitOps” 一体化工具链。顺带说一句：这是 2025 火山引擎 FORCE 大会上刚发布的产品，免费版和 Plus 版都开放，9 月前能直接上手全功能体验。现在市面上很多 prompt 工具做的是“编辑器 + 改写器”，但你会发现，真正上线之后需要的是一整套治理机制。 PromptPilot 是我目前看到国内第一个跑通这个闭环的，不是 fancy 的界面，而是认真在解决 prompt 系统演化能力这个问题。如果你也在做 AI 应用落地，推荐你认真研究一下。要说缺点：自定义模型没找到海外模型，差评！

#火山引擎 #PromptPilot #Google doc管理 #Prompt优化 #提示词白皮书 #工程问题