凡人小北

统计数据

48

文章

0

粉丝

0

获赞

270

阅读

1天前

ChatGPT 的记忆系统更新了，一个不起眼但可能非常关键的底层变化：自动管理记忆，不再 memory full，也不再全靠你手动删改。一觉醒来 AI 在自我意识觉醒的路上的又迈出了一小步。 OpenAI 官方是这么说的： 1. 不会再提示“记忆已满”，系统会自动合并 / 替换不再重要的信息 2. 支持搜索、排序、设定记忆优先级（by 你自己） 3. Plus 和 Pro 用户今天起全球上线（仅限 Web 端）没想到今年 memory 发展这么快，控制权开始往模型转移了。 ChatGPT 自动判断哪些对用户重要，并且只保留它觉得重要的，还能定期合并、更新、删除不再需要的内容，最主要的是这些判断都是来自系统本身的策略模型，而不是用户。脑补一个对话： “我们上次聊的那个方向呢？” “我已经归档了，觉得它没那么有用。” 这还是个工具吗？🤔 听起来是不是有点像人？跟前两天那篇推文说的一样，记忆系统这事儿，光是能存起来远远不够，OpenAI 的记忆架构应该是有一些突破了。当然了，现在它还不算真正自主记忆管理，但这个功能很明显的趋势，未来的 AI，不一定记得你告诉它的，但会自主判断它认为你重要的。有点意思但又细思极恐！

#ChatGPT记忆系统 #AI自主学习 #OpenAI #记忆管理 #细思极恐

1天前

突然 FDE（Foward Deployed Engineer 前沿部署工程师）这个词火得有点莫名其妙，很多创业者一夜之间开始膜拜 Palantir 式打法，搞得好像硅谷又发现了什么新大陆。先说我的看法：国外现在兴奋讨论的这套东西，中国人早就在用了。不夸张地说，FDE 这个概念在国内 toB 创业环境里，根本不是什么未来范式，它是过去 10 年我们活下去的方式。硅谷的 FDE 模式今天之所以被捧上神坛，是因为 AI agent 产品天然不能标准化、不能纯靠 SaaS 拉起规模，只能靠“深扎现场 + 产品抽象 + 高难度交付”（这几个词眼熟吗）这种非线性方式打通从 0 到 1 的路径。这种新范式我们不叫 FDE，我们叫它：售前 + 客户经理 + 实施 + 技术支持 + 专人陪跑 + 项目现场 + 临时产品经理是不是听上去不那么高级，也没人总结成Echo + Delta 团队这样的理论模型可中国 to B 创业者、尤其是医疗、制造、政企、教育领域的创业者，从来没有什么 SaaS 福报。我们走进客户现场，用工程师替客户解决一线需求，项目经理拆用例，售前写方案，然后陪标、上系统。这些人一开始就被扔进落地即交付，交付即定制的泥沼里，硬生生走出了一套非标准化探索到产品复用化的路径。所有这些国外今天才开始鼓吹用 demo 去找 PMF，我们已经 demo 到脱发了。欧美 SaaS 怕是忘了东方还有个神奇的国度。为什么现在大家把 FDE 当作一种新的 go-to-market 策略来膜拜。可能是因为他们原来做的是标准化 SaaS，突然卷进 AI agent 的复杂场景，一下子手脚不够用了，才发现：哦原来世界上还有一种方式，叫“没有产品也要先干起来”？

#FDE #toB创业 #中国经验 #AI Agent #非标准化

2天前

《为什么 95% 的 AI Agent 做不起来？》非常推荐，踩的坑和解决方案跟我们几乎一模一样，虽然讲得很清楚，架构师视角，值得花 10 分钟读完，应用到工程实践中。几个点： 1. 现在大家都还在拼 prompt，只有少数人开始拼上下文结构。特别对的一点是：prompt engineering 已经不是核心了，context engineering 才是下一阶段的主战场。给再聪明的大模型喂进去一堆乱七八糟的输入，它还是只会胡说八道。市面上跑得稳的 Agent，都是在“什么该让模型看、怎么看、以什么形式看”上下了大功夫的，这一点现在应该是共识了。 2. 记忆系统这事，光是能存起来远远不够很多公司的 memory，说得好听点是长期记忆，难听点就是个聊天记录仓库。真正落地的系统要分层记忆（用户级 / 团队级 / 系统级）。文章读完我感觉更多的篇 B 端，C 端要思考的是结合业务来做分层记忆，并且要能让人知道它记住了什么，并且用户能自己改。否则就不是记忆是监控。 3. 不迷信单模型，这年头还不做 routing 的 agent 就别说自己做 infra 了。这篇文章提到多模型路由，说得很对。不可能所有请求都丢给 GPT5，成本和时延直接炸掉，表现也未必好。真正合理的系统，一定是：快速反应的轻模型做分类和前处理、重模型做主任务、补一个模型做验证或追问。一个 agent 后面绑定的一定是一个 LLM 团队。 4. 可追溯/可控/可信，是企业愿意用 Agent 的底线很多人只想着怎么让 agent 能回答，但企业更关心：这句话是从哪里来的？有没有越权？出了错我怎么追责？ AI 要可治理。 5. 最被低估的一点：Agent ≠ Chatbot 这篇文章最后说到的一点我非常赞同但还不够狠：如果还在用聊天当所有用户交互的方式，那agent 最多是个语音助理。真的 agent 应该是：先用语言调度任务，然后在页面上看到结构化结果，还能继续点选、调整、组合下一步。这部分很多公司现在在尝试了，交互上比之前全部自然语言高效了太多。一个特别有意思的点，当主持人问观众“你们中有多少人构建了文本到 SQL 并投入生产？”时，没有一个人举手。

#AI Agent #Context Engineering #多模型路由 #可追溯性 #人机交互

1周前

最近在看一圈 ToB agent 的落地情况，有个判断越来越清晰：至少还得 1 年，国内 ToB agent 才可能真正起来。第一，国内的模型能力，还不够。 ToB 业务链条长、场景复杂、对结果的容错率极低。现在的大模型，哪怕再微调十遍，稳定性不够，自洽性不够，还不够听话这些问题依然严重。 prompt 写得挺对，它干的事还是不怎么靠谱。像个刚转岗的实习生，流程懂了点，但是做起来全是 bug。第二，做技术和懂业务的，不是一拨人。 ToB agent 最大的挑战是知识怎么迁移。比如想让 agent 搞懂保险理赔、医疗问诊、法律审查……这些不是写 prompt 能解决的，它们背后是几十年经验、人情流程和模糊判断。越值钱的知识，掌握它的人越年长，越难被结构化表达，更别说这批人愿不愿意倾囊相授。技术今天搞出来一个 agent，业务方只会说三句话：你这不准啊、我们流程不是这样的、你这漏了关键条件，但这个流程是之前开发跟业务一起梳理出来的。这背后藏了抵触，技术和业务之间，隔着的不是 AI，是一整座山。那为什么 AI coding 能先跑出来？因为这事里最懂业务的就是技术自己。谁最懂代码结构？技术！谁能写 agent 调 agent？技术！谁能 debug agent？还是技术！技术是唯一一拨能自己用，自己调 bug的群体。业务等于本体，没有认知 gap，也不需要跨专业翻译，一整个闭环自然就跑通了。本质区别在这：AI coding 是单边迁移服务自己， ToB agent 是双边博弈，需要认知共建。一个能快，一个必须慢。对于 AI coding，只要模型理解开发者就够了。ToB agent，不仅模型要懂业务，开发者还得懂业务，然后两边还得对得上话。这，太难了。真正的转折点要出现：必须满足模型能稳定编码行业知识，Agent 能封装复杂动作并处理结果反馈（前提是老顽固们愿意掏心窝），企业能放心把核心流程交出去。到那一天，ToB 才真正算是 ready 了。那时候再回头看 coding agent 的进化速度，也许已经不是一个量级的对比了。技术在革自己命这件事上，从来没有输过任何群体。

#ToB agent #大模型能力 #技术与业务认知差异 #AI Coding #行业知识迁移

1周前

OpenAI 又把AMD 拉了进来，再加上Oracle、博通这些公司，基本已经形成了一个小圈子。大家一起玩，股价/估值互相复利向上，市值层层往上叠。一座巨大的围城已然形成。外面的公司看热闹，里面的人越抱越紧，创新的空间能被他们的效率吃得干干净净。这是史上效率最高的资本共生体了吧。

#OpenAI #AMD #资本共生 #科技围城 #高估值

2周前

这个九月 AI 工具真的卷出新维度了。Flowith 把自己的画布升级成 Context Playground（AI 创想画板）。用 AI 最烦的就是它总是自己嗨，幻觉一堆，明明只是想改一点点内容，就跑偏了八百里，最后却不得不一遍一遍地试探 prompt…… 现在，Flowith 直接让我一刀剪掉跑偏的部分，AI 幻觉真的被解决掉了。它把整个创作流程换了种思路，用户第一次真正能在一张画布里自由的创作。整张画布顺畅的就像是一个“灵感搭建场”，AI 不再主导，而是变成真正的工具层助手，我更愿意称现在的这个形态为“无边记”。

AI视频井喷：Midjourney领跑，多模态混战· 251 条信息

#AI工具 #flowith #Context Playground #AI创想画板 #无边记

2周前

几十张发票折腾了两个小时的一点感想，都2025年了，怎么财务流程还这么原始。很多公司财务流程，电子化了喊了几十年，但真正要报个销才知道，系统里还得一张张自己填发票信息，填完打出来贴一起，然后交给财务人工复核，再一张张录回系统、签字、盖章…… 这流程是电子化吗？是的；但是省事了吗？半点没有。就像个四不像：电子发票+手动填系统+打印纸质+线下走流程，原本应该节省人力的地方，现在变得双倍折磨人。改革最怕的不是没做，而是做了一半就停了，还觉得自己已经转型成功了。关联到 AI 也一样，很多公司就掉进了类似的坑里，提效口号喊的震耳欲聋，其实只是在叠流程为了 AI 而 AI。新东西加上去，旧东西又没砍掉。这样的改革是最消耗人的，员工觉得麻烦加倍，管理者却以为效率提升，结果就是整个组织处于一种伪提效的状态里。我特别想说一句，要改革得让相关的流程习惯和管理逻辑都得跟着动。

#财务流程繁琐 #电子化改革失败 #伪提效 #AI应用问题 #管理逻辑滞后

3周前

一年一度的云栖大会，吴泳铭开场这场就扔了个长线炸弹“AGI只是起点，ASI才是终极目标。” 直接把话题拉到了“超级人工智能的三阶段进化路线” 这个提法我还是第一次在国内大厂 CXO 层面听到这么系统地说。跟我的判断一样，阿里云真的在按操作系统的方式做 AI。如果说 OpenAI 和 Anthropic 还在强调模型智能，阿里现在直接开始讲系统调度和电网级布局了。他讲 AI 的三阶段进化路径： 1）智能涌现，2）自主行动，3）自我迭代。这条路径其实暗含了一个判断：人类对 AI 控制权的下沉，是随着“数据-工具-反馈”这个三元系统一点点转移的。越往后，AI 自主权越强，人类在链条上的必要性越低。常年做 Agent 系统的人真的很有体感，从workflow到agentic，真正的自我推进式 AI，从系统设计上还远远没做好。 “自主行动”这一阶段我觉得非常关键。吴说核心是 Tool Use + Coding + Agent，这一段我直接脑补公司正在构的 agent 编排平台的最大痛点就是：模型能调用工具，但不会判断工具是否合适；能 coding，但缺少代码行为的后果感知。现在大多数系统都停留在调用工具这一层，有开始往下延伸到 agent 能否规划子任务、能否收集结果反推 prompt 的部分，但做的都一言难尽。所以他说：“未来，自然语言就是 AI 时代的源代码”，我个人非常认同，但补一句：要让自然语言真的成为源代码，Agent 必须会调试自己。然后讲到第三阶段自我迭代，我能关联到开头asi，这是真系统了。吴用了“连接原始数据 + 自主学习”来解释这个阶段，说白了就是 AI 不再靠人类喂数据，而是能像机器人那样自己感知世界 + 自己训练自己。我们现在做的 AI 训练，几乎都是在人类整理后的结构化结果上精调，你从来不给它原始混乱数据，后训练时代也鲜有加入做错后的直接代价。但没有代价，哪来迭代？没有原始世界的反馈闭环，AI 只能永远在沙盒里复读旧人类。所以才有了模型为了输出一个所谓的答案，全是幻觉。（未完）

#吴泳铭 #ASI #AGI #阿里云 #AI自主权

3周前

在 OpenAI 最新那篇《How People Use ChatGPT》的研究报告里，可以看到一个很多技术人不愿意承认的事实。我们天天讨论 AI 的未来、模型的能力、Agent 的协同，但普通人真正反复在用的确是最不起眼、最没技术含量、但最能偷懒的那一类小脑力动作。很多的创业方向都是 AI 重构操作系统，但在报告里能看到的基本都是这样的提问场景： “我懒得写，你帮我润色下” “这事我大概懂，但你能快速解释一下吗” “我脑子卡住了，你先给我几个思路我再改” 就是这类小到不能再小、但一天下来会出现无数次的轻认知需求。要说这些任务值钱吧，好像也不大值钱；但要说不值钱吧，每一次都真想掏出点什么东西来换时间、换注意力、换一口气不费脑的轻松感，于是，这反而成了 ChatGPT 用得最频繁的几个场景。报告里有个特别关键的数据点：写作、实用建议、信息查询这三类用途，加起来占了用户对话的大头。注意！！！不是图像生成、代码开发和多模态探索之类的，就是字面意义上的“你帮我想点内容”、“你帮我写点东西”、“你告诉我这个怎么做”，极其朴素、但极其高频的脑力协助。更有意思的信息是，真正把这三类用法用在工作场景中的人占比也很高，尤其是在教育程度高/收入水平高/日常脑力劳动密度大的人群中。也就是说大量的高认知人群的低成本输出策略，用 AI 省点脑子，完全不是因为不会做，单纯的不想做或者不想做得那么费力。我意识到一个很本质的判断转变，AI 应用不应该去比谁更智能，而应该去比谁更懂人类和人类不想动脑的那一瞬间。很多技术人一个很大的错觉，以为大家想要一个能回答所有问题的 GPT，其实大家更想要一个能帮他们免于思考前5分钟的小工具；以为用户要的是全链路智能流程，其实用户更需要的是一个“我脑袋转不动了你先帮我垫一脚”的认知助理；以为大家要构建的是一个 super agent，但现实中能留下来的产品，很多时候可能只解决了一个问题，比如：懒得写。也正因为这样，我现在看“做什么 AI 应用能赚钱”这个问题，视角已经完全变了。别去想还能不能做一个内容平台、一个垂直模型、一个 SaaS 系统。应该反过来去问自己：我有没有办法，找到一个特别具体、特别细分、但特别常见的人类偷懒瞬间，然后围绕这个瞬间，去设计一套轻决策路径 +提示词模板 + 好的 UI 输出，让用户在最不想动脑的时候，最快拿到可修改的半成品。而当这个偷懒动作被频繁触发，它就自然变成了习惯性的AI 肌肉记忆，而我们所做的应用，也就从一个工具变成了大脑外挂。那 AI 产品的商业价值又该如何定义，可能有一类不在于能不能模拟一个人类专家，而在于能不能替用户做掉那些明明可以做但就是不想做的动作。真正的市场不应该只盯着智能的天花板，往下看看，再懒惰的地板上也有大量的机会。那再 AI 革命的宏大叙事下，我们追求的就不只是让人更强，让人更轻也应该进入视野。人类会为强大而敬畏，但也会为轻松而掏钱。思考下自己的日常，再环顾下市场，一个值得做的 AI 应用，不一定惊艳，但一定能替人类懒一次。所以，你想不想做一款 AI 产品，能替用户少动一次脑？你能不能用 prompt、memory、数据和一点点贴心，帮人类多偷一秒懒？如果可以，那它可能比我们写出一个能做十种事情的智能体，还更容易被买单和留存。这类的机会还有很多。

OpenAI GPT-5发布引发用户不满，阿尔特曼回应质疑· 100 条信息

#ChatGPT #AI应用 #用户需求 #偷懒 #轻认知需求

3周前

作为懒猫微服的用户，最让我惊喜的是他们家丝滑到不行的客服。一客一群问啥都秒回、解决问题不绕弯，体验完全不像传统厂商那种冷冰冰。这种服务感受，对我来说是很大的加分项。

#懒猫微服 #客服 #服务体验 #积极 #用户感受

1个月前

🔗链接在这里：

#标签1 #标签2 #标签3

1个月前

看到微软开源的一个项目 MarkItDown，这么小的一个工具获得了 7w+ star。但它干的事儿特别朴素，把各种格式的文件（Word、PDF、Excel、PPT、图片、音频、HTML、JSON、甚至 zip 包）一键变成结构化 Markdown。是的，保留标题、列表、表格、链接结构的那种 Markdown。为什么我会觉得这个工具值得讲讲？因为这其实解决了一个我们常常下意识忽略的问题：在做 AI 工具链 / 多模态 Agent 的时候，非结构化文件怎么喂给模型？怎么结构保留？怎么对齐输入？ MarkItDown 把这事儿做成了入口标准件。它让我们可以构建一条干净的链路： 1. 业务文件/网页/对话记录/OCR 结果 → Markdown with structure 2. 再接入 LLM、embedding、Agent 或私有知识库系统整个链条让每一个本来不适合进 AI 的文件，都变得适合进 AI。就这一点，已经超越了文件格式转换工具的定位，把它当成 AI 里文档智能的基建模块也不为过。 pip install 或者用它提供的mcp版本，就全搞定了。微软这波是真的懂工程师在处理数据入口时的痛点。这项目能有这么多 star 是因为它处理的恰恰是所有 AI 工作流都要面对的最前一公里。文件乱、格式多、结构丢失等一系列这琐碎问题解决不了，后面你那套 pipeline 其实跑不通的。未来我们肯定会有越来越多“agent + 数据 + 多模态”的场景，那些 agent 想干活，第一件事就是把一堆烂七八糟的原始资料读懂，还原出它的结构和语义。 MarkItDown 说白了就是把这个入口的苦活累活都干了。这种不 infra 的工具往往才是最重要的 infra。推荐给所有做 LLM 产品的人。

#微软 #MarkItDown #AI工具链 #多模态Agent #文档结构化

1个月前

我见过更丝滑更变态的链路： - 现场扫码 → 跳转公众号 - 关注公众号 → 自动推送消息 - 消息点开 → 企微二维码 - 加企微 → 欢迎语发个 H5 - 点进 H5 → 要先注册登录 - 登录后 → 观看品牌视频满 10 秒 - 看完才解锁「下单按钮」 - 点完还得支付，支付成功后 → 才能拿到所谓的“小礼物” 你没看错，这已经是 8 步操作 + 4 次跳转 + 2 次扫码的超级链路。一环套一环，像极了舔狗在追求女神时候被动接受的行为训练。每一步都像一扇门，每一个动作背后都绑定了某种数据采集、分发节点、用户识别或系统打标签。这背后是留下了你的微信openid、直播/地推标记、判断是否二次触达、真要跳出了，还能下次再精准喂你广。这个世界早没资格谈什么纯粹的互联网了。现在是反用户体验工程的工业化时代。

#用户体验差 #过度营销 #数据收集 #流程繁琐 #反用户体验

1个月前

Claude 封中国公司，有人问我怎么看？我觉得这事让 AI 赛道出现了一个明确分界线，从现在开始，你是谁、你在哪、你背后是谁，决定了你能不能用最强的能力。只要是中国资本控股的公司（不管你注册在哪），统统禁止使用它的服务，也不管你有没有违规，直接封。这里面几个点， 1. 科学无国界，但模型能力分国界，至少对于 Claude 模型已经从工具变成了阵营资产。 2. Claude 这次封的是所谓的不可控身份，只要股东是中国公司，它就不想让你接触它的模型。 3. 灰色链路要开始加速崩溃，很多创业团队这些年靠香港身份/海外公司/API 代付等一系列操作合法使用御三家，现在 Claude 是第一个把身份写进服务条款的平台，以后类似封锁很可能会成常态。再聪明的架构也扛不住对方一句我们不接受你的存在威力猛。Claude 只是第一个，不会是最后一个。AI 的玩法要变天了，但是 Claude 的老板为什么对中国敌意这么大？

#Claude #中国公司 #AI 赛道 #身份限制 #地缘政治

1个月前

最近跟不少朋友聊企业搞 AI 落地，从各种 bot 进化到各种 Agent，气氛都很热，但项目的真实进展却远不如预期。大家所在公司的状态都差不多：老板特别兴奋，业务不愿意用，技术反复沮丧。展开聊聊，欢迎对号入座。这个话题涉及其实到一个老大难的组织张力：老板、技术、业务之间的“不可能三角”。很多时候事情本身与要推广的技术无关，这其实是博弈路径走歪了，大部分都卡死在老板、技术、业务这三方的拉扯中。 1/ 先说老板，他们想要的很简单： - 资本市场上能讲故事，能拿融资、能PR，能上 AI 战略； - 业务角度又要 ROI 快，最好 3 个月就看到节省成本或增长 GMV；所以经常一拍脑袋下个大决策。但他不会告诉你落在哪，也不会等你慢慢迭代，不超三月耐心可能就没了。 2/ 那技术团队怎么想？技术团队很纯粹，全部站在技术角度出发： - 要做效果好的，还得是多模态的； - 要兼顾成本、推理速度、数据合规；技术特别擅长造工具箱，但常常不知道业务到底要锤哪颗钉子。大部分情况下的结果就是 Demo 特炫酷，ppt呈现的花里胡哨，但一到落地就一地鸡毛。 3/ 那业务呢？其实业务最现实： - 用户用不用、能不能转化、有没有 KPI 提升； - 能不能马上见效，不然就又是个花瓶；他们天然不信技术团队，也很难有意愿撇开 KPI 不达成来尝试新鲜玩意，一看就这效果基本就甩手不用了。 4/ 于是形成 AI 落地最经典的三角困局： - 老板 push 战略 → 技术找不到抓手； - 技术 all in AI → 业务根本不接这茬； - 业务只要 KPI 结果，并且做好了功劳是技术的 → 老板觉得这只是当下价值，我们还要未来；这三方之间没有解法，只有来来回不断的妥协和博弈。 5/ 所以很多人说要破局，就要搞懂技术、搞懂产品，但其实最难的是搞懂组织。 AI 从来不是技术项目，而是组织协作项目，这也是我为什么一直说 AI 一定是一把手工程，是要老板撸起袖子上亲自上的，不是挂个技术负责人就能搞定的。大家坐在一起，让老板接受 MVP，让技术理解转化漏斗，让业务团队参与 Prompt 打磨。 6/ 在我参与的多个 AI 落地项目里，最顺畅最高效跑得通的路径基本是这个顺序： - 业务牵头，选一个最小闭环场景； - 技术配合打工具链，能量化、可解释 - 老板做资源担保，别中途撤退、别急功近利也不是说技术牵头搞不定，但这条路径一定是磨难最大的，过程中各种资源、阻力。 7/ 所以如果你正在推进企业 AI 落地，试着画一画你们的权力三角：谁是真正说了算的人？谁在扯皮？谁在躺平？很多时候是三方角力最后没有一方能走出共识的幻觉。那咋落地，一定得先过组织这一关。合适的人选是能在老板、技术、业务之间架桥的人，这个人可能是技术、可能是业务，所以你要在内部推 AI 项目，要首先找到这个关键节点，这样会顺利不少。啰嗦这么多，其实这一句是我这两年最大的经验。

#企业AI落地 #组织协作 #老板、技术、业务三角困局 #业务牵头最小闭环 #一把手工程

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浪潮：重塑就业，风险暗涌？· 112 条信息

#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 工具

2个月前

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

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

2个月前

纳米 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

2个月前

去年我第一次用 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 辅助编程

2个月前

《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系统 #上下文管理

2个月前

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

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