十人以内的团队能否维持服务质量，自动化能否覆盖异常情况，创始人的判断会不会成为新的瓶颈，都要在业务增长后接受检验。

图由 AI 生成

文 | Alex

基础设施公司通常文档比代码厚。SandBaseAI 走了另一条路。

这家公司做的是 Agent Platform，Agent Runtime 是底层核心。它位于大模型与 Agent 应用之间，把模型、工具、沙箱、浏览器自动化等能力接到一起。Agent 进入真实业务后需要的权限控制、状态管理、故障重试、日志追踪和成本管理，也由这一层承接。

这是 AI 产品链路中工程密度较高又很难通过一段 Demo 展示的部分。SandBaseAI 的核心团队只有三个全职成员和一个兼职合作角色。

三名全职成员都是全栈工程师，没有单独的销售、运营、产品经理、测试或设计岗位。团队分布在英国、加拿大和北京，官网全英文，客户主要来自北美、欧洲、中东和东南亚。

这支远程团队很少维护传统知识库，也没有常态化会议。

工作思路、客户反馈和产品变化先在群里同步，再写入一份供人和 Agent 共同调用的“共享上下文文件”。Codex、Claude 和工程师由此使用同一套产品边界、接口约定和决策背景。

SandBaseAI 的产品和组织沿用了相近的设计，把分散的执行能力接进一套系统，减少中间转交；方向、取舍和责任留给人。

01 Agent 为什么还跑不起来？

SandBase创始人李样兵把 Agent 行业过去几年的变化概括为三次迁移：

• 第一阶段比模型能力，行业关心模型能否理解和回答；
• 第二阶段比调用效率，关注模型能否以更低成本、更快速度、更稳定地被使用；
• 进入第三阶段，竞争开始转向执行环境。

Agent 作出判断后，能否调用工具完成任务，能否持续运行，出错后能否追踪，权限和成本能否控制，成为产品进入生产环境前必须解决的问题。

“模型决定能力上限，但决定 Agent 能不能进入生产环境的是运行平台和交付体系。”李样兵说。

一个 Agent Demo 可以在短时间内搭出来。

接入一个模型，连接几个工具，再设计一条工作流，屏幕上很快就能出现结果。到了正式产品阶段，状态保存、代码执行、浏览器操作、账号授权、日志观测、失败重试和计费会同时出现。

开发者往往要连接多家模型、沙箱、搜索、浏览器和数据服务供应商，再自行处理接口变化与链路故障。

SandBaseAI 希望把这些分散能力封装在一个平台里。李样兵把它比作“AI 产品装配工厂”，开发者选择所需模块，完成组合和品牌定制，再把产品交付给自己的客户。

平台服务两类人：

• 一类是构建 Agent 产品的 Builder，他们需要快速调用模型、接入工具，把想法变成可以运行的产品；
• 另一类是把 Agent 带进企业现场的 FDE 和交付团队，他们更关心系统能否稳定运行，以及任务失败之后如何恢复。

一条工作流里只要有一个接口调用失败，后续任务是否继续、状态如何恢复、责任怎样定位，都需要平台给出答案。Runtime 的价值大多发生在后台，很少有视觉冲击，却决定着一个 Agent 能否从演示走进生产。

02 三个人写代码，也接客户、签合同、买物料

SandBaseAI 于 2026 年 7 月正式组建。

采访时，团队共有三个全职成员和一个兼职合作角色。三名全职成员都做研发，其中一名工程师同时负责客户对接、合同和物料采购；李样兵与另一名工程师也直接参与客户沟通、需求梳理和项目落地。

基础设施工程、产品抽象和开发者运营没有被拆成三个部门。

团队从客户问题出发，把重复出现的需求抽成平台能力，再通过内容和开发者运营让用户理解产品。少数几个人沿着同一条链路工作，很少经过岗位之间的反复转交。

产品、测试和设计等工作依然存在。它们不再对应一组固定岗位，由工程师、创始人、Agent 和自动化脚本共同承担。

• 客户反馈由创始人和工程师直接判断，Agent 辅助生成需求说明、接口文档和用户路径；
• 测试结合自动化脚本、真实请求和 Agent 生成的用例完成；
• 界面设计更多依靠组件库、参考产品和快速迭代。

李样兵把这类人称为 AI-native Builder 或 AI-native Operator。他们要能写代码、理解客户场景、组织上下文、验证 Agent 的输出，再把一项任务推进到交付。

传统岗位名称很难完整概括这类人的工作。

按照团队内部的估算，在原型开发、API 接入、测试用例、文档生成和客户问题排查等环节，一名熟练使用 Agent 的强工程师，产出可以达到传统方式的两到三倍。这个数字来自团队自身经验，暂时没有统一口径可供横向比较。

李样兵更在意人效出现的前提。

一个人如果不会拆任务、组织上下文和验证结果，Agent 很可能加快错误和返工。AI 会放大有能力的工程师，也会放大含糊的需求与混乱的协作。

SandBaseAI 招人主要看三项能力：

• 从具体需求中抽出稳定平台能力的系统抽象能力；
• 持续学习新模型、协议和工具的能力；
• 对稳定性、安全、成本和可维护性负责的工程意识。

应用可以快速试错，基础设施出现问题，影响的是客户系统、任务执行、账单和业务连续性。

03 不写 Wiki，人和 Agent 共用一份“说明书”

李样兵说他们“不写文档”。

在他看来，AI 行业变化太快，昨天形成的方案，今天可能已经失效。

团队如果花费大量时间整理静态文档，内容往往还没被充分使用就开始过期。SandBaseAI 很少按传统方式积累知识库，日常讨论和工作结论会先同步到群里。

但团队仍然维护一份共享上下文文件。

这份文件同时写给人和 Agent，里面记录 SandBaseAI 的产品定位与边界，不同场景何时使用 API、CLI 或 MCP，哪些接口已经稳定，哪些仍在实验，以及哪些内容可以对外表达。

每次接口变化、重要决策或关键客户反馈，都会更新到这份上下文中。工程师调用 Codex 修改 API，或者让 Claude 整理文档时，模型先读取相同的背景，避免各自形成一套产品理解。

这份文件是产品文档、工程约定和组织记忆的共同入口。

普通知识库主要保存过去，共享上下文还要进入下一次任务。内容需要保持结构化、可调用，并跟随产品变化持续更新。

对一个完全远程、没有中层的小团队来说，上下文也承担了一部分管理工作。

SandBaseAI 会在群里同步行业判断、产品变化和客户反馈，产品调用量、错误率、收入趋势等关键数据尽量向核心成员开放。

工程师知道客户为什么付费，才能作出合适的技术取舍；负责外部沟通的人了解系统边界，才不会作出超出产品能力的承诺。

投资、薪酬和敏感客户合同仍有权限限制。团队追求的是与产品决策有关的信息充分流动，并不要求所有信息无差别公开。

共享上下文也需要维护。哪些变化必须写入，旧信息何时删除，不同 Agent 读取到的版本是否一致，都会影响最终输出。

现在，这项工作还能由创始人和核心工程师共同校准。以后成员增加、客户场景变复杂，维护上下文本身就可能变成一项新的组织职能。

04 人不能把判断外包出去

李样兵认为，一个AI 原生组织遇到问题，要先判断能否通过 AI 标准化处理，再决定是否增加人手。

在 SandBaseAI 内部，代码、测试、文档、客户问答和内容生产都大量使用 Codex、Claude、内部 Agent 和自动化工具。产品方向、商业取舍、客户优先级和风险边界，仍由人决定。

“Agent 可以做很多事，但创始人不能把判断外包出去。”他说。

这条边界来自他此前的 AI Infra 创业经历。

上一段创业中，团队较早按照传统方式拆分职能。人数增加后，工程、产品和业务之间开始反复传递信息，沟通成本随之上升，决策速度反而慢了下来。

这一次，李样兵计划把核心团队长期控制在十人以内，不设置中层，非核心工作更多交给工具或外部合作方。人少带来的直接变化是，信息不需要经过多层转述，决策可以更快进入执行。

与此同时，判断压力也集中到了少数人身上。

产品做什么、暂时放弃什么，哪些客户值得服务，哪些收入可能把产品带偏，都需要创始人持续介入。Agent 可以生成方案，却不会承担客户流失、系统故障和战略失误的后果。

SandBaseAI 把大量执行交给 Agent 和工具，让核心成员共享产品与业务信息，最后由人完成取舍并承担结果。三个半人的规模，正是这套分工在当前阶段形成的组织形态。

05 卖 API 养活今天，做 Runtime 押注明天

底层平台需要长期投入，早期客户很难把核心系统直接交给一家刚成立的公司。SandBaseAI 的销售从迁移成本较低的模型和 API 服务开始。

这类服务对客户现有业务改动较小，也更容易产生早期收入。API 调用是这个团队增长最快的收入来源。

SandBaseAI 已经形成常态化营收，但未披露具体规模。团队通过轻量服务积累客户与使用数据，再逐步增加沙箱、浏览器自动化、工具接入、状态管理和可观测等平台能力。

目前，SandBase的产品已经完成 MVP，并开始支持客户交付，距离完全自助使用还有一段路。

团队采取“陪跑式打磨”，一边参与客户项目，观察问题具体出现在哪一步，一边简化操作流程，目标是让用户最终能在几分钟内完成 Agent 产品的组装。

陪跑越多，工程师投入客户项目的时间越长。客户数量增长之后，三个半人的团队很快会碰到产能上限。

反复出现的问题能否被抽成标准能力，用户能否独立完成更多操作，决定了这套产品能走到多大规模。

上游供应商也在持续变化。模型、沙箱、浏览器和工具接口一旦调整，就可能影响整条工作流。

SandBase需要在平台内部消化这些变化，再向下游提供相对稳定的入口。

抽象太浅，平台容易退化为接口转发；抽象太深，又会限制开发者的灵活性。因此，稳定和自由之间的尺度，需要在一次次产品迭代中调整。

随着模型调用逐渐标准化，SandBase希望平台收入更多来自底层拼装、运维与交付时间的节省。客户愿意为“工程时间”和“交付确定性”支付多少费用，还要由更长周期的收入、续费和使用数据回答。

SandBase目前的组织方式，与公司的业务和阶段密切相关。

• 它服务的是开发者和交付团队，核心用户本身具备较强的技术能力；
• 产品仍处在 MVP 和早期商业化阶段，创始人可以直接参与产品、研发、客户和运营；
• 公司暂时不承担大规模本地部署和复杂企业交付。

销售、实施、客服和管理岗位的需求由此被压低。当更多客户把生产任务交给平台，稳定性、安全、合规、服务响应和业务连续性的责任会随之增加。

十人以内的团队能否维持服务质量，自动化能否覆盖异常情况，创始人的判断会不会成为新的瓶颈，都要在业务增长后接受检验。

栏目介绍 

本文为崔牛会「AI 原生组织研究」系列文章。更深层的问题，比如人在 AI 原生组织中如何重新定义价值，AI 输出如何被工程化约束，中层管理在新组织里会不会消失，已经收录在崔牛会9月2日发布的《AI原生组织白皮书（2026）》中。

关注公众号：拾黑（shiheibook）了解更多

[广告]赞助链接：

四季很好，只要有你，文娱排行榜：https://www.yaopaiming.com/
让资讯触达的更精准有趣：https://www.0xu.cn/