凡人小北

统计数据

67

文章

0

粉丝

0

获赞

466

阅读

2个月前

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

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

2个月前

一年一度的云栖大会，吴泳铭开场这场就扔了个长线炸弹“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自主权

2个月前

在 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发布引发用户不满，阿尔特曼回应质疑· 158 条信息

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

2个月前

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

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

2个月前

🔗链接在这里：

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

2个月前

看到微软开源的一个项目 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 #文档结构化

2个月前

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

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

2个月前

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

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

3个月前

最近跟不少朋友聊企业搞 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落地 #组织协作 #老板、技术、业务三角困局 #业务牵头最小闭环 #一把手工程

3个月前

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安全流程

3个月前

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

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

3个月前

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

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

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

3个月前

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

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

3个月前

小红书上刷到张咋啦总结的 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

4个月前

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

4个月前

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

4个月前

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

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

4个月前

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

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

4个月前

很多技术博客看完就忘，但 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 控制能力？你的记忆系统是全塞还是挂载的？

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

4个月前

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

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

4个月前

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

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

4个月前

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

4个月前

吴恩达上个月在 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 重写业务系统，建议把吴恩达这场演讲当作创业者操作系统升级的读本。技术潮水会一直往前涌，但真正能穿越周期的，只有一个问题：你是不是真的比别人更快做出来、更快做对、更快做成。