椰果点心的博客

目录: 为什么Token是Agent工程的第一性原理？ 多：模型类型多，按需调度 不是所有任务都需要Opus 多模型编排的实战模式 快：响应快，延迟低 Token生成速度是用户体验的生命线 快的关键技术：投机执行与预取 缓存：不消耗Token的”快” 好：完成效果好，质量高 “好”是最难优化的维度 用更多Token换更好的结果 提升”好”的工程手段 省：成本低，花得值 Token经济学：一笔账算清楚 省的六个杠杆 上下文窗口管理：最容易忽视的成本黑洞 多快好省的动态平衡 悟空的启示：Token Native思维 参考资源 1962年，一位伟人为中国工业发展题写了”鼓足干劲，力争上游，多快好省地建设社会主义”。六十多年后，当我们审视AI Agent工程的核心挑战时，会发现一个惊人的对称：Agent工程的终极优化目标，本质上就是对模型Token消耗的”多快好省”。 淘宝用十五年把”多快好省”刻进了中国零售的DNA——商品要多、物流要快、品质要好、价格要省。而今天的AI Agent Runtime，正在用同一套逻辑重塑Token消费——模型类型要多、响应速度要快、完成...

目录: 启示一：“软件构建”远不止编码，它是专业性的基石 Skill 编写：AI 时代”软件构建”思维的典范 启示二：战略性构建你的生涯，而非随机”跳荷叶” Skill 生态：工程师构建”职业金字塔”的新基石 启示三：AI 时代，工程师的终极价值是追求”完全正确” Skill 编写指南：追求”完全正确”的实战教科书 Skills 的本质：把”怎么做”变成资产 从《代码大全》到《Skill 编写大全》：跨越二十年的传承 二十年前，Steve McConnell 的《代码大全》(Code Complete 2nd) 以其近 900 页的体量，成为软件工程领域一座难以逾越的丰碑。二十年后，它依然是无数工程师书架上的必备经典。在一场深度的访谈中，McConnell 分享了这部巨著背后的故事、对职业发展的深刻洞见，以及对 AI 时代的冷静思考。 尽管技术浪潮已更迭数代，但 McConnell 的核心思想依然闪耀着永恒的光芒。我从中提炼出三大”启示”，它们穿越了语言和工具的变迁，直指软件开发的本质。而当我读完 Anthropic 刚刚发布的 The Complete Guide...

Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub. Quick StartCreate a new post1$ hexo new "My New Post" More info: Writing Run server1$ hexo server More info: Server Generate static files1$ hexo generate More info: Generating Deploy to remote sites1$ hexo deploy More info: Deployment

目录: 传统文档的根本问题：只留结果，不留过程 AI 时代的转折点：会话本身就是知识生产 从”结果导向”到”过程导向” AI Native 文档的三层架构 第一层：会话层——捕获原始认知过程 第二层：萃取层——从对话中提炼结构化知识 第三层：知识图谱层——建立知识之间的关联 会话数据的独特价值 1. 隐性知识的显性化 2. 决策的完整上下文 3. 认知演进的轨迹 实现路径：从会话到知识的四个关键设计 设计一：会话即草稿 设计二：自动知识萃取 设计三：知识的版本化和演进 设计四：组织级知识网络 与传统知识管理的本质区别 这意味着什么 企业每天都在产生大量知识，但绝大多数知识从未被记录下来。不是因为没有文档系统，而是因为真正的知识不在文档里，而在产生文档的过程中。 一份产品方案的最终版本只有 10 页，但写这 10 页的过程中，团队讨论了 20 个方案、否定了 15 个、在 3 个关键决策点上反复权衡。这些讨论、推理和决策——才是企业最有价值的知识。传统文档系统只保存了结论，丢掉了思考。 AI Native 文档要解决的，就是这个问题。 传统文档的根本问题：只留结果，不...

目录: 一句话理解 Agent 架构 五层架构总览 第一层：用户交互层 第二层：任务编排层——Agent 的大脑 1. 任务分解与规划 2. 权限与治理 3. 资源调度 第三层：能力层——Agent 的技能树 Prompt：即时指令上下文 Skills：过程知识 Projects：长期知识库 Workspace——贯穿全局的运行容器 问题一：持久上下文 问题二：Agent 协作 问题三：可审计 问题四：运行环境 推荐目录结构 第四层：执行层——Sub-Agent 与 Runtime Sub-Agent：任务执行单元 Runtime：执行引擎 第五层：连接层——MCP 统一外部访问 完整执行流程 架构设计原则 原则一：Skill 多，Agent 少 原则二：复杂任务必须拆分为 Sub-Agent 原则三：Workspace 是系统核心 原则四：Skill 必须结构化 原则五：MCP 是唯一外部入口 结语 很多团队对 Agent 的理解还停留在”LLM + Prompt + 几个工具调用”。这种理解能跑通 Demo，但一旦进入企业级场景——多任务并行、多系统集成...

最近在梳理各种 AI Agent 框架和 Runtime 的架构时，我产生了一个越来越强烈的感觉：我们正在重新发明 Unix。 不是比喻。是字面意义上的重新发明。当你把今天主流的 Agent 架构摊开来看——Skill、Workspace、Tool、Pipeline、Orchestrator——你会发现，这些概念和 50 年前 Unix 的设计哲学几乎一一对应。区别只是换了一层 AI 的皮。 两条被反复验证的 Unix 原则Unix 哲学有很多条目，但最核心的两条，几乎定义了整个操作系统的灵魂： 1. Make each program do one thing well. Write programs that do one thing and do it well. Write programs to work together. — Doug McIlroy 2. Everything is a file. 在 Unix 中，普通文件是文件，目录是文件，设备是文件，管道是文件，套接字也是文件。一切通过统一的 open/read/write/...

传统 IM（即时通讯）解决的是一个简单的问题：让人和人高效地交换信息。文本、图片、文件、语音——三十年来，IM 的核心架构围绕着”谁说了什么”展开，安全靠端到端加密，权限靠静态角色控制，审计靠消息日志。这套体系服务了几十亿用户，足够成熟。 但当 AI Agent 成为 IM 中的活跃参与者——不仅接收消息，还理解意图、调用工具、执行任务、产生后果——传统 IM 的架构假设就被从根本上打破了。IM 不再只是信息传递的通道，而是 Agent 协作与执行的操作系统。 这需要一种全新的 IM 架构。 传统 IM 的四个假设，正在被 AI 打破传统 IM 的架构基于四个核心假设。这些假设在人与人通信的场景下完全合理，但在 Agent 参与的场景下每一条都不再成立。 假设一：消息就是文本传统 IM 的消息单元是文本、图片、文件——本质上是信息的载体。接收方（人）自行解读消息的含义，决定是否行动、如何行动。 但 Agent 收到的消息不只是信息，而是可能触发执行的指令。一条看似普通的消息：“帮我把这份合同发给张总”，对人来说只是一个请求，但对 Agent 来说是一个需要执行的操作链——找到合同...

当我们谈论企业级 AI Agent Runtime 时，第一个需要解决的问题不是”模型有多聪明”，而是”Agent 执行的代码有多安全”。一个能读写文件、执行命令、访问网络的 Agent，如果没有安全边界，就是一颗不知道什么时候会爆炸的定时炸弹。 企业级的 Agent Runtime 首先需要一个安全沙箱：文件系统隔离 + 网络访问隔离。 为什么 Agent Runtime 必须有沙箱？传统软件运行在用户的权限下，执行的是人类编写的、经过代码审查的确定性代码。AI Agent 完全不同——它执行的代码来自大模型的实时推理，具有不确定性。更危险的是，Agent 可能被**提示注入（Prompt Injection）**攻击劫持，执行攻击者想要的操作。 没有沙箱的 Agent Runtime，面临的风险是真实且严重的： 风险一：凭证窃取12345# Agent 被提示注入后可能执行的命令cat ~/.ssh/id_rsacat ~/.aws/credentialscat ~/.npmrc # 包含 npm auth tokencat ~/Library/Keychains/* 用...

和企业客户聊 AI 落地，十次有九次会被问到同一个问题：“我们调用你们的大模型，数据会不会被拿去训练？” 这个问题背后的焦虑是真实的。企业的客户数据、商业机密、内部文档、代码仓库——这些是企业的核心资产。把它们发送给一个外部的大模型 API，本质上就是把家底给别人看了一遍。如果这些数据还被用来训练模型，那等于是在免费帮竞争对手提升 AI 能力。 好消息是，这个问题在 2026 年已经有了成熟的解决方案。坏消息是，大多数企业还不知道该怎么选。 企业的三层焦虑企业对调用大模型的数据安全焦虑，可以分为三个层次： 第一层：数据会不会被用于训练？ 这是最基本的焦虑。如果企业发送的 prompt 和回复被模型厂商用来训练下一代模型，那就意味着企业的私有数据”融化”进了一个公共模型中，理论上可能通过其他用户的查询被间接泄露。 第二层：数据会不会被人看到？ 即使不用于训练，数据在传输和存储过程中是否可能被厂商的员工访问？是否有日志留存？如果被监管机构调取，数据在哪个管辖区？ 第三层：数据会不会离开我的控制范围？ 对金融、医疗、政府等强监管行业，数据不能离开特定的物理位置或网络边界。即使厂商承诺不...

目录: 一个 Agent 被多个群共享，到底有多危险？ 1. 会话上下文（Session Context） 2. 长期记忆（Memory） 3. Agent 工具能力（Tool Access） 两种隔离，缺一不可 会话隔离：Session 的颗粒度设计 方案一：按用户维度（不隔离） 方案二：按会话类型隔离 方案三：群内用户级隔离 记忆隔离：比会话隔离更关键 Agent 隔离：不同的群，不同的 Agent Bindings：基于规则的 Agent 路由 不同 Agent 实例意味着什么？ 典型攻击场景与隔离方案 场景一：跨群信息窃取 场景二：权限提升 场景三：记忆投毒 场景四：提示注入执行链 企业级隔离架构设计 第一层：消息路由层（必须） 第二层：会话隔离（必须） 第三层：Agent 隔离（强烈建议） 第四层：沙箱隔离（企业必须） 配置即安全策略 结论 把一个 AI Agent 拉进钉钉的多个群，是一件非常容易的事情——群管理员点一下”添加机器人”就完成了。但这也是一件极其危险的事情——如果 Agent Runtime 没有做好隔离，你可能正在制造一个企业级的...