老树开新花：中小团队的 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 的组织应该满足三个条件：

1. 组织内所有信息对 Agent 可读
2. Agent 和人类一样，参与到生产决策的过程中
3. 整个 Agent 的决策、执行、结果是一个闭环可验证的链路

（这三个条件后面第四节会展开讲怎么一步步做到。）

我会认为 AI Native 的组织大概率只能从零新建。一个全新的组织从零搭这个框架相对容易，没有历史包袱。但一个跑了很多年的旧组织想做到 AI Native，坦白说很难——旧的流程、旧的系统、旧的人员结构，每一层都有阻力。

但 AI Native 不是终极目标，它是一个方向。 不同类型的组织，都可以沿着这个方向努力，享受到 Agent 时代的红利。

最理想的做法是单拉出来一块业务，从零开始做，没有历史包袱，一切围绕让 Agent 更好地进入组织去设计。选哪块业务？标准是：数据链路相对封闭、数字化程度较高、能快速看到 ROI。退而求其次，就是在现有组织里做渐进式改造——虽然很难达到 AI Native 的理想状态，但一样能获得实实在在的提升。

还有一点非常关键：与物理世界关联深的业务，先补数字化基建。 真正 AI Native 的组织，主要业务的所有信息都能在线上获取，闭环是打通的。但在商业一线，很多东西跟物理世界紧密关联——库存在仓库里、样品在货架上、供应商的报价在微信语音里。这些东西如果没有完成数字化，Agent 再强也无从下手。

二、一把手工程，优先做大盘子

Agent 在组织里落地，有两个方向的效果：降本增效和做大盘子。

降本增效相对好量化、好达到，所以这大概是绝大多数老板推进的切入点。但如果从这个点切入，有一个天然的问题——它会跟组织内部的人员形成利益分野。你用 Agent 替掉了某个环节，这个环节原来是有人负责的。这种事不太适合一个外人去推。

另一个角度是做大盘子——用 Agent 拓展新的业务、提升产出上限，拿新增的利益来分享。这样阻力会小很多。当然，有些行业确实没那么多增量空间，被倒逼着只能走降本增效的路。

不管走哪条路，有一点是确定的：Agent 落地是一个一把手工程。

为什么？因为你节省的每一个环节，本质上都是在对权力的地盘进行重新划分。如果没有顶层的授权，也没有一个既懂业务又懂 Agent 的角色来牵头推进，基本上很难让组织真正享受到 Agent 红利。

同时，不应该以 100% 的 AI 使用率来衡量落地效果。拿跨境电商来说，做供应链的同事，你想让他既精通供应链又精通 AI，这种人才太稀缺了。而且说实话，这种人才大概率也不太可能在你的组织里待得住——除非你舍得分钱。

所以，正确的方式不是全员推进，而是分层推进。

三、人员三层架构

我理解下来，传统团队转型 Agent 时代，人员应该是这么分层的：

graph TB
    A["顶层：组织架构师（1-2 人）
搭基础组件、定架构"] --> B["中层：一线实践者（3%-5%）
搭业务工作流、写 Skill、分享经验"]
    B --> C["基层：跟随者（大多数人）
Follow SOP、提供数据反馈"]

    style A fill:#9b59b6,color:#fff
    style B fill:#3498db,color:#fff
    style C fill:#2ecc71,color:#fff

顶层：组织架构师（1-2 人）

一个既懂 Agent 又很懂业务的人，来搭整个团队的基础组件：建立唯一的业务数据源、设计权限治理机制、搭建技能分享平台、构建反馈迭代的闭环。

中层：一线实践者（3%-5%）

组织内少量愿意积极拥抱变化的人。他们在真正的业务过程中用 Agent 解决问题、提高效率、做出成果。这些人来搭业务侧的"枝干"：具体的工作流、好用的 Skill、跟 Agent 交互的经验。

这些人因为有 Agent 协助，在业务上也会做出比较好的成果。然后大部分人本质上是"因为看见所以相信"——当组织内有这么一小撮人真的用好了 Agent，并且做出了成果，其他人自然会跟上。

你需要用机制来鼓励和引导他们做分享。

基层：跟随者（大多数人）

大部分人其实是 follow SOP、follow Skill——这些 SOP 和 Skill 来自中层实践者的沉淀。基层员工不需要深度理解 Agent，只需要按照搭好的流程操作，在过程中提供数据反馈——让整个 Agent 体系有更多的行为数据输入。

至于最后一小撮非常抗拒 AI 的人，本质上就是算一个 ROI 的问题。有些人确实在物理世界里有很深厚的积淀，他脱离 AI 的能力依然很强，那也没办法，大家还是算账的嘛。择其优者合作，不强求。

Token 成本跟着分层走

这个架构还有一个好处：成本可控。只有顶层架构师和中层实践者才需要高质量的 Token 来思考（用顶级模型设计方案框架、编写可复用的自动化流程），大部分人配一个便宜的执行模型就够了。

这就是我在 风控、设计哲学与模型选择 里讲的策略：顶级模型定思路，国产模型搞好工程降成本。 在组织层面同样适用。

关于 AI 时代的组织变革，强烈推荐听一下 XMind 联合创始人 Mango 的分享：分活，分圈，分钱，搞 AI（AI 总结与校对稿）。XMind 从部门制转向"圈子制"的一手施工经验，核心结论是：AI 原生组织的目标是尽量减少人与人之间的摩擦，凡是有摩擦的部分能自动化就自动化。怎么分圈、怎么分活、怎么分钱，这期节目讲得非常透。

四、上下文：价值上最核心，技术上最容易着手

前面讲的都是组织层面的障碍——权力、利益、人员结构。把这些条件扫清之后，接下来就是在技术上把上下文做好。

有一个判断我越来越确信：一个顶尖模型配一个垃圾上下文，效果不如一个普通模型配一个顶尖上下文。 这在 Context is All You Need 里已经展开讲过，这里不重复。

在组织层面，上下文的建设有三个层次，每往上一级，Agent 能发挥的价值就上一个台阶：

这三层是阶梯递进的。每往上一层，Agent 在业务中的参与深度就上一个台阶，带来的价值提升也是台阶式的。

但这一切的前提是——数字化基建得先做好。

唯一数据源：飞书多维表格

组织内的业务数据不能散落在 A 的 Excel 里、B 的微信聊天记录里、C 的脑子里。如果这个基础的数字化建设都没做好，就不要妄想 Agent 能给你带来什么大的提升。

对于中小团队，我的建议是：用飞书的多维表格作为你业务上的唯一数据源。

为什么是飞书多维表格？

• 它相当于一个小型数据库，但不需要你付出很大的人员养护成本——中小团队的限制就在于此，你不太可能自己去维护一套复杂的数据库
• 飞书提供了全面的 API 和 飞书 CLI（相当于 Agent 操作飞书的工具箱），可以很方便地让 Agent 直接读写多维表格里的数据
• 再结合飞书自带的工作流、权限管理和多设备同步，一个常见的业务系统就能跑起来了
• 这里说句实话，钉钉和企微的表格能力跟飞书比差距还是蛮大的。如果历史包袱不重，建议单独买飞书多维表格

当然，飞书多维表格有行数限制，进阶到一定程度之后你还是得上自有数据库。但在草创阶段，它完全够用了。

历史遗留系统：想办法接进来

现实中总会有历史系统的包袱。有的有 API，有的只有网页操作界面，有的甚至只有 Excel 导入导出。

但不管怎样，你得想办法把它们接入到整个基础设施里，让 Agent 能触达。方式很多——有程序接口的直接对接，只有网页操作界面的可以用自动化工具模拟人的点击操作来接入，只有 Excel 导入导出的就做自动化的数据搬运。

物理世界的数字化映射

跨境电商里有大量跟物理世界关联的东西：库存数量、商品实物、供应商的聊天记录、会议录音……这些东西都应该尽量以映射的方式构建出数字版本——唯一的商品 ID、库存数量、供应商沟通记录的转录文本，等等。

无非就是耗点磁盘空间。但长期来看，这些数据才是组织内部最大的财富。哪怕现在处理不了，随着 AI 能力的进步，将来都能被很好地利用起来。

最简单的第一步：把所有会议用录音转文字工具转成文本存下来，成本几乎为零。

核心心法

把 Agent 当成一个新入职的员工来看待。它要完成一个任务，到底还缺哪些信息？缺什么你就给它补什么。

自检一下：你团队的核心业务流程里，Agent 想参与但目前拿不到的信息是什么？那就是你要优先数字化的东西。

五、不追求 Token 使用量，追求单点替换

搭好了数据源、建好了上下文之后，怎么衡量落地效果？这里有一个常见的误区：给每个人发一个 Agent，配一个 WorkBuddy 账号，然后看谁的 Token 使用量高——这个指标毫无意义。

真正有意义的是：围绕业务流程，让 Agent 做单点替换。某个环节原来由人做，现在换成 Agent 做，效果更好、速度更快、成本更低。一个点一个点地替换，是最切实可行的方案。

具体的模型使用策略也跟着分层走：顶级模型用来设计方案、搭框架、编写 Skill；便宜的模型按 Skill 做执行、跑操作、收集 feedback——这样执行结果又能反馈回来优化下一轮决策，形成闭环。

甚至大部分情况下，Agent 做的事情就是执行一个工作流。很多东西用 Workflow 就能做，Agent 来写这个 Workflow 也完全没问题。

少部分人在搭业务工作流，其余人有 SOP 可以参照，可能原来需要手动做的工作变成了点几个按钮、做一个审批。这样从组织利益上来看，相对比较好往前推。

六、MCP：让 Agent 调用工具的标准协议

在讲基础设施之前，需要先解释一个概念：MCP（Model Context Protocol）。

你可以把 MCP 理解为 Agent 世界里的"USB 接口标准"。Agent 想查数据库、想发消息、想搜网页、想调用公司内部的某个服务——这些都不是 Agent 天生就会的，它需要通过 MCP 去"连接"这些工具。

每个 MCP 服务需要运行一个 Server 进程，会占用内存和计算资源。MCP 服务大致分两类：

• 外部服务：比如 GitHub、Google 搜索、各种 SaaS 平台提供的官方 MCP 接口
• 内部服务：部署在公司服务器上的。这又分两种——纯自建的系统（比如公司自己开发的库存管理接口），以及在开源社区基础上部署的工具（比如 n8n 就提供 MCP 服务，Agent 可以通过它触发和管理工作流）

如果每个员工的电脑上都各自跑一堆 MCP Server，不仅浪费资源，管理起来也是噩梦。这就引出了下面的基础设施设计。

七、基础设施：一台服务器撑起整个团队

团队和个人用 Agent 最大的区别是什么？团队内的东西可以复用。 你搜过的内容我不用再搜一遍，你调通的 MCP 服务我不用再配一遍。所以基础设施层面，一方面要把缓存和共享放在核心位置，另一方面也要考虑权限分离和日志审计——谁用了什么、花了多少、有没有越权，这些在团队场景下必须可追溯。

这里有一个关键的架构理念：服务端-客户端分离。

所有重活跑在公司的一台服务器上，员工的电脑只是一个轻量的操作入口。这样：

• 不用给每人配高性能电脑
• 不用每人本地起一堆 MCP Server
• 所有服务统一管理、统一更新

以下推荐的工具，除特别标注外均为开源项目，在一台普通服务器上就能全部跑起来，部署成本非常低。

① AI 中转网关：New API

场景：公司买了 Claude 和 GPT 的 API，想让 10 个员工都能用，但不想把原始密钥发给每个人。

New API 就是干这个的。它是一个 AI 模型的统一中转网关。上游可以接各类官方 API 通道，也可以接你采购的中转站渠道，甚至是通过技术手段从其他渠道获取的 Token——对下游来说完全无感知。下游可以控制每个人能用哪些模型、花多少钱，既可以给人用，也可以给组织内部的软件系统用。比较好算账，也好控制权限。用的人很多，功能迭代一直在跟进。

开源，免费。

② API 密钥网关：Key Proxy

场景：运营要用 GPT 生图，设计要用第三方的去水印 API，选品要调用某个数据平台的接口。每个服务都有自己的密钥——总不能把原始密钥发给每个人吧？但让每个人自己注册，报销和管理又是一团糟。

New API 解决了大头的模型 Token 中转，但它管不了这些长尾的 API 服务。而且大部分 Skill 在设计的时候都是为单个人、单个 Agent 设计的，本身就没有考虑多人多 Agent 的使用形态。你需要的是一个通用的 API 密钥网关——把公司采购的各种服务的单一密钥，分发成团队内部的多个密钥。每个员工只需要一把钥匙，就能开所有的门。

这里面要有日志留痕、权限控制、花费控制。这块我自己写了一套叫 Key Proxy，没有开源，但思路是通用的。

③ Skill 版本管理：SkillHub

场景：某个同事写了一个特别好用的 Skill，比如"一键生成竞品分析报告"。他想分享给全团队。现在的做法是往群里丢一个压缩包——两天后有人改了一版又丢一个，一周后没人知道哪个是最新的。

SkillHub 是讯飞开源的 Agent 技能注册平台。它解决的就是 Skill 在团队内的版本化管理——上传、审核、分层权限、一键安装，相当于团队内部的 Skill 应用商店。

开源，免费。

④ MCP 服务聚合：MCPHub

场景：Agent 要调用各种 MCP 服务——连 GitHub 的、搜竞品数据的、查公司库存的。如果每个员工的电脑上各自起一份这些 Server，10 个人就是 10 份内存开销，而且配置管理是噩梦。

MCPHub 是一个自托管的 MCP 网关。把所有的 MCP 服务统一部署在服务器上，通过 MCPHub 聚合起来，给下游提供统一的接入点。员工的 Agent 客户端只需要连接 MCPHub 这一个地址，就能使用所有的 MCP 工具。

再接一层 Key Proxy 的话，还能实现权限控制——谁能用哪些 MCP 服务，一目了然。

开源，免费。

⑤ 搜索和爬虫中心

场景：三个运营同时让 Agent 搜同一个竞品的 TikTok 数据。不做缓存的话，就是三倍的 API 调用成本，还可能因为同一个 IP 出口频繁访问被平台风控。

不同 Agent 的搜索能力参差不齐，而搜索能力本身是构建上下文的重要组成部分。组织内部应该有一个统一的搜索和爬虫中心：

• 缓存：搜过的内容缓存起来，避免重复调用的成本浪费
• 聚合：对外搜索（TikTok、Instagram、电商平台）、对内搜索（企业资料库），统一接口
• 异步和并发：多个 Agent 同时发起搜索请求，系统要能扛得住
• 风控：统一处理爬虫的频率控制和 IP 管理，不让每个人的 Agent 各自裸奔

这块我也是自建的，没有开源，但任何一个有搜索需求的团队都应该考虑做这件事。

全景：一台服务器上的全家桶

graph TD
    subgraph Client["员工电脑（不要求高性能）"]
        Proma["Proma · Windows / Mac"]
        CC["Claude Code / Codex"]
    end

    subgraph Gateway["公司服务器 — 网关层"]
        NewAPI["New API · 模型网关"]
        KeyProxy["Key Proxy · API 密钥网关"]
        SkillHub["SkillHub · Skill 应用商店"]
    end

    subgraph Services["公司服务器 — 服务层"]
        MCPHub["MCPHub · MCP 聚合"]
        Search["搜索中心"]
        Video["视频理解 API"]
        N8N["n8n · Workflow"]
        MCP["其他 MCP Server"]
    end

    subgraph Upstream["上游 API 来源"]
        Official["官方 API"] ~~~ Reseller["中转站"] ~~~ Sub2API["Sub2API"]
    end

    Proma -- 调用模型 --> NewAPI
    CC -- 调用模型 --> NewAPI
    Proma -- 使用工具 --> KeyProxy
    CC -- 使用工具 --> KeyProxy
    SkillHub -. 安装 Skill .-> Proma
    SkillHub -. 安装 Skill .-> CC

    Upstream --> NewAPI

    KeyProxy --> MCPHub
    KeyProxy --> Search
    KeyProxy --> Video
    MCPHub --> MCP
    N8N --> MCPHub

重点：所有重活都在服务端，客户端只是操作入口。 员工不需要高性能电脑，不需要自己配置任何服务端的东西。这对中小团队来说非常友好——投入一台服务器的成本，就能让整个团队的 Agent 基建跑起来。如果有一个懂技术的人专职推进，上面这些开源工具从部署到跑通，大约一到两周。

说句题外话：上面提到的所有自建系统（Key Proxy、搜索中心），加上这些开源服务的部署和运维，都是我一个人在做。在 Agent 时代，这些事情真的不难——这本身也是前面"顶层架构师只需要 1-2 人"的一个佐证。

补充一点：网络安全

Agent 现在的能力非常强，但能力强也意味着安全风险大。如果有条件的话，还是建议对服务端的网络做一定程度的隔离——防止恶意攻击通过 Agent 直接进入组织内部。这个话题太复杂，几句话讲不清，但至少要有这个意识。

八、客户端：按需配置

根据实际观察，组织内部也就 3%-5% 的人 Agent 用量特别大——基本就是前面说的那批中层实践者——其他人用得都很少。所以不需要给每个人都开最贵的账号。

非技术人员重点推荐 Proma——这是我目前能找到的最好的开源免费通用 Agent 客户端：

• 不绑定单一大厂生态：可以接任意 OpenAI 兼容的 API，配合 New API 使用自己的密钥，成本非常可控
• 更新非常频繁：社区活跃，功能迭代快
• 非技术人员友好：UI 清晰直观，操作简单，Windows 和 Mac 都有客户端

直接接前面搭好的 New API，对办公场景来说是一个很好的通用 Agent 入口。

技术人员用 Claude Code 或 Codex，这个不用多讲。

如果完全不想自建后端，腾讯的 WorkBuddy 也是类似定位的产品，充值即用，不需要自己搭 New API。但 Proma 的优势在于可以接自建的 New API 后端，成本和权限都自己控制。稍微有一点技术能力的话，还是建议搭前面说的那套基础设施——长期的成本优势和管理便利性是完全不同量级的。

九、从 Workflow 到 Managed Agents：三级台阶

个人使用 Agent 客户端是容易的，但让 Agent 在企业层级 24 小时运行，是另一回事。这里有一个清晰的递进路径：

第一级就是前面讲的日常状态。重点说说第二级和第三级。

Workflow + LLM：大部分企业的主战场

绝大多数企业内部场景，用 Workflow + LLM 调用都能解决。 这可能是目前被严重低估的一条路。

推荐工具是 n8n——一个开源的 Workflow 自动化引擎，部署在前面提到的那台公司服务器上就行，和其他服务共用一台机器，不需要额外成本。

n8n 在 Agent 时代的使用方式需要做一个转变：不是由人手动在界面上拖拽创建工作流，而是让 Agent 通过 MCP 和 Skill 来创建和维护 Workflow。同时，把团队里那些共用的逻辑节点抽象成 n8n 的 Node，长期迭代，方便基于工作流进行自由拼接组合。

自动化的过程中，有 LLM 的参与、有 Agent 的介入——这本身已经是非常大的进步了。

托管 Agent 运行时：进阶话题

再往上一级，就是真正的自主 Agent——可以长时间运行（几分钟到几小时）、定时调度（cron）、调用各种工具。Anthropic 提供了 Claude Managed Agents 这套托管平台，开源社区也有类似思路的项目，比如 TrueForge。

但说实话，这个层级对企业的要求已经非常高了——完善的权限策略、MCP 服务体系、安全凭据管理，每一项都不简单。我们自己在这块的体验也还不深，这已经是另一个话题了。

大部分中小团队，先把 n8n 这层做扎实。

写在最后

回到开头那个判断：个体提效 10 倍容易，组织提效 20% 困难。

但困难不代表不能做。这篇文章讲的就是一个传统团队能走的路：

• 不需要追求 AI Native，沿着这个方向渐进式推进就好
• 先补数字化基建，飞书多维表格就能解决大部分问题
• 人员分层推进，不追求全员使用率，用成果带动"因为看见所以相信"
• 用开源工具搭基建，一台服务器就能跑起来，成本极低
• Workflow 是主战场，90% 的企业场景用 Workflow + LLM 就能解决

核心是两件事：在组织层面扫清权限、基建、利益分配的障碍，在技术层面给 Agent 充分的上下文并打造闭环。

只有闭环了，Agent 在企业内部才能根据历史数据回测分析，持续提升。这样你的组织才会长期有 Agent 带来的增量。不然的话，只要这个链路中任何一个点是断的，Agent 就只能是一次性的工具——用一次就没有下一次了。

闭环了才有增量，有增量才值得持续投入。这个理念，我觉得比任何具体的工具选型都重要。

附录：给 Agent 的参考资料

以下内容面向 Coding Agent（Claude Code / Codex 等）。如果你是人类读者，可以跳过这部分——把整篇文章的链接发给你的 Agent，它会自己来读这一节。

开源工具清单

以上工具均支持 Docker 部署，可以部署在同一台 Linux 服务器上，推荐用 Docker Compose 统一编排。

相关文章

• Context is All You Need：上下文工程基础
• 风控、设计哲学与模型选择：模型分层策略
• 将军赶路不追小兔：多 Agent 调度体系
• Agent 不下班：远程开发环境搭建
• Claude Managed Agents：Anthropic 官方托管 Agent 平台

推荐播客

• XMind Mango：分活，分圈，分钱，搞 AI：老牌软件公司从部门制转向"圈子制"的组织变革一手经验（AI 总结与校对稿）

本文由飞书录音豆语音转文字构思底稿，通过 Claude Code + Opus 4.6 对话完成文章架构设计与内容整理。