Agent

众人拾柴火焰高 这篇写给一类特定的读者：很懂自己的生意，但没有技术背景的老板，尤其是中小企业主。延续这个系列的传统——作为人类，你只需要读懂思路；具体的执行细节，交给你的 Agent。 引子：如果你本来就是老板 最近 FDE（Forward Deployed Engineer，驻场交付工程师）这个词特别火。这个说法因美国的 Palantir 而出名——一家给政府和大企业做数据平台的公司。Palantir 用 FDE 来称呼它的一种工作方法：派工程师常驻客户现场，贴着真实业务把系统一点点改出来。它还有一个核心概念叫"本体论"（Ontology），大白话说，就是把企业现实里的业务——商品、订单、供应商、它们之间的关系、能对它们做的动作、谁有权限做——在数字世界里完整地建一个模型，然后用数据分析、用 AI 去优化它。 这个词传进国内之后，就变成了一个筐，什么都往里装。随便翻几家公司的招聘就能看出来：同样叫 FDE，传音要的是帮内部业务部门把 Agent 用起来，中兴新云要的更像去客户那里找机会、出方案的咨询顾问，遇碳科技要的则是去客户机房里把模型装好、调通的实施工程师。市面上还有更宽的说法：帮客户把一条流程做成全自动、替掉几个人，叫 FDE；给客户定制一套软件，也叫 FDE。 但不管怎么定义，行业里绝大多数的讨论都是乙方视角：我怎么进客户现场、怎么取得信任、怎么摸清需求、怎么熟悉一个陌生行业、怎么交付拿结果。 这篇文章换一个视角——甲方视角。 如果你本来就是老板，你根本不缺乙方最缺的那些东西：你最懂自己的行业，最懂自己的客户，最懂自己的团队。你真正的问题不是"我怎么做一个 AI 项目"，而是： 未来三五年，模型每年都在变强，我的公司要怎么持续吃到这个红利？ 我的答案先放在这里： 不要追求今天就拥有最先进的 Agent 系统。要努力把公司变成一个"模型越强，自己就越受益"的组织。 下面展开讲为什么，以及怎么做。 一、为什么写代码最先被 AI 攻克 先看一个现象。 AI 写代码的能力，去年大概还是个小学生，今年已经能顶替很多顶级工程师了。做 Claude 的 Anthropic 和做 ChatGPT 的 OpenAI，都在官方文章里（Anthropic、OpenAI）公开过：公司内部八成以上的代码，已经是 Agent 在写。 至少在软件工程里，“写代码"这件事基本已经被解决了。 为什么偏偏是写代码最先被攻克？不是因为模型天生偏爱代码，而是因为代码世界天然具备两个条件。我在上一篇文章《吃一堑，长一智》里，把它们概括为 Agent 时代最重要的两个词： 上下文（Context）：Agent 做事时能看到的所有信息。在代码世界里，代码本身、改动历史、报错日志、说明文档，全都是现成的、数字化的，Agent 随手就能拿到。 闭环（Loop）：做完一件事，能马上知道做得对不对，并且把教训带到下一次。在代码世界里，改完一行代码，跑一下测试，十几秒就知道对错。错了就改，改了再测，一天能转几千圈。 上下文决定 Agent 这一次做得好不好，闭环决定它下一次能不能做得更好。 信息现成、对错立判，所以 AI 在代码世界里进化得飞快。 换成生意里的话说： 上下文，就像你招来一个新运营，第一天要交接给他的那些东西：商品资料、历史销量、哪个供应商靠谱、上次为什么砍掉那一款。这些交接不到位，再聪明的新人也只能瞎猜。Agent 也一样。 闭环，说白了就是复盘。只不过要把"当时为什么这么决定"和"后来结果怎么样"记在同一个地方，下次 Agent 做判断前能先看到。 拿补货举个完整的例子： ...

吃一堑，长一智 这篇的底稿是两段加起来 80 多分钟的语音分享。依然延续这个系列的传统——作为人类，你只需要读懂思路和逻辑；具体的执行细节，把文章丢给你的 Agent 就行。 引子：两个关键词 今天聊一个稍微有点抽象的命题：如果 Agent 时代只能记住两个词，应该是哪两个？ 第一个毫无疑问是 Context，上下文。 从模型训练用的数据，到模型应用时你给它的代码仓库、企业知识、个人习惯，本质上都是上下文。按我自己的经验，输出好不好，大半在开口之前就定了：你给了它什么材料，留了什么规矩。这也是我之前那篇 Context is All You Need 想表达的逻辑。 第二个词，我认为是 Loop，循环，或者说闭环。 一件事只有迭代成闭环——有日志、有记录可以复盘，改完之后又能验证结果——Agent 才能不断提升自己的决策质量。这其实已经有点模型训练的雏形了，更进一步就是大家常说的自我进化。听上去有点高大上，但它完全可以落到我们自己的工作流里：有意识地去构造 Context，有意识地去构造 Loop。 这两个词之间的关系，就是这篇文章的主线： 静态的 Context：预先写好的东西。规则文件、技能包、记忆、工具配置。 动态的 Context：只能从 Loop 里长出来。你做了验证、拿到了结果、复盘了错误，这些新信息再回流成下一次的上下文。 全文主线：静态的 Context 预先写好，动态的 Context 从 Loop 里长出来 先拿个具体的数字感受一下。我有个仓库叫 agent-config，专门放我所有 AI 工具的规则和调度脚本，7 月 23 日建的。两个月过去，它累积了大约 1.6 万次提交（每一次修改记录）、1800 多个 issue（待办和问题单）、将近 2000 个合并的 PR（改动提案）。这些全部是 AI 提交的，这个仓库我自己没有写过一行代码。 我现在每天大概消耗 20 到 30 亿 Token（含缓存读取）。几个月前，我得一直高频盯着、基本人在环内（people in the loop），才能维持每天 40 亿左右的消耗；现在消耗还是这个量级，我每天只花一小部分时间在 Agent 上，不影响干别的事。凭体感说，投入的精力下降了一个数量级，单个项目明显省心得多。 ...

老树开新花 这篇文章的底稿是一段 45 分钟的语音思考。延续这个系列的传统——作为人类，你只需要读懂思路和框架；具体的执行细节，交给你的 Agent。 文末附录里有给 Agent 读的参考资料。 前置推荐阅读：Context is All You Need（上下文工程基础）、风控、设计哲学与模型选择（模型分层策略）、将军赶路不追小兔（多 Agent 调度体系）。本文聊的是一个不同的视角——不是"我个人怎么用 Agent"，而是"一个传统团队怎么让 Agent 落地"。 开篇：为什么聊这个话题 过去半年我写了不少关于 Agent 的文章，但都是个人视角：我怎么搭环境、怎么调度、怎么在手机上遥控。这篇换一个角度——组织视角。 我目前在一个跨境电商的业务团队里，推进团队借助 AI 来提效、提规模。从流量端到供应链端，这是一个非常传统的行业，团队里什么角色都有——做投放的、做运营的、做供应链的、做设计的。这不是一个从零建起来的 AI 公司，而是一个已经跑了很多年的旧组织，想要在 Agent 时代找到新的增长空间。 以下基本上都是我的一手实践经验。 为什么要加上"中小团队"这个限定词？因为对大部分中小型团队而言，合规法务上的要求没那么重，公司内部一切以效率为主，很多东西实际上比较草莽。这样的话，你在推进过程中可以因为追求效率来接受一部分合规成本——等问题先出现再处理，是一个可接受的范围。这是大企业做不到的事。 在开始之前，先说一个我越来越确信的判断： 个体提效 10 倍是容易的，组织提效 20% 是困难的。 为什么？因为组织提效不只是上下文的问题——它涉及权限审批、基础设施建设、权力划分，这些组织层面的障碍才是真正难啃的骨头。上下文在技术上反而是最容易着手的部分，但这不代表它不重要——恰恰相反，上下文的质量对 Agent 的输出质量是决定性的（我在 Context is All You Need 里详细讲过）。而协作本身就是有损的：信息在人和人之间传递，一定会丢失、变形、延迟。 所以在 Agent 时代，协作其实是一个次优解。最高效的方式是：完整的业务上下文在一个人的脑子里，由这个人借助 Agent 去 handle。每多加一个人参与，你都应该多想一步——这个人是不是非加不可？还是 Agent 就能替代这个协作环节？ 这不是说不要团队，而是说 Agent 时代的组织优化方向，不是"让更多人更好地协作"，而是"让更少的人借助 Agent 覆盖更大的范围"。 带着这个前提，我们来聊怎么在一个传统团队里落地 Agent。 一、AI Native 是方向，不是目标 先说一个定义。我体感下来，一个 AI Native 的组织应该满足三个条件： ...