给每个部门配一个AI，反而更难用

团队最早的做法，是按角色拆了四个专属 agent：一个客服 agent（PINE）、一个数据分析 agent（Pinewood）、一个工程 agent（Pinecone）、一个销售 agent（Reggie Jr）。这个思路听起来直观，实际用起来却出了问题。

表面的问题是员工要记住哪个 agent 管什么事，团队又偏爱松树主题命名，PINE、Pinewood、Pinecone 放在一起并不好分辨。更深层的问题是，公司里真正重要的工作大多跨部门进行，很少只发生在一个部门内部。

公司本质上是一堆待完成的工作的集合。以发布一款产品为例，它牵涉技术团队，也牵涉销售、市场、法务、运营。部门之所以存在，是因为一个团队或一个人做不完整件事的所有部分。AI 正在改变这一点，它能越来越多地把一件事从头做到尾。

这个道理，Sierra 在自己的产品上已经验证过一次。用 Sierra 搭出来的 agent 是全流程的，一个 agent 能处理从产品咨询到开户、排障、账单在内的所有环节，不是老式 IVR 那种客服请按 1、销售请按 2 的分流方式。

把所有事收进一个 agent，让公司离真正的价值更近，那些待完成的工作本身。每一次改进都惠及整个公司，所有人都跟着变快。

好agent自己知道该什么时候出手

大多数工作不是一次对话就能做完的，它要跨越几天、几周甚至几个月，团队在这中间不断学习、优先级不断变化、新信息不断出现。一个只在被提问时出现、会话一结束就消失的 agent，用处有限。

持续带着上下文，也让 Pinecone 变得主动。它不用等着被问，而是在下一步准备就绪时就动手，比如某个产出物触发了一个 webhook、一个任务进了 Linear、一份评审送达。它会先收集上下文，动手做第一遍，再把需要判断的部分交给人。开会前，准备笔记已经等在那里；面试结束前，访谈纪要已经起草好；评审送达时，已经带着摘要、关键风险和建议意见。目标不是增加更多通知，而是减少那些送到手上却还没做完的工作。

这一步团队还没完全做到，多数会话仍然由人先开口。但把这个顺序倒过来，让 agent 在需要时主动来找人，是持续性正在带着团队走的方向。

拦住AI的，是它不懂你公司

过去卡住 AI 的是模型本身够不够聪明。今天的前沿模型，智商已经够用了。真正的瓶颈搬到了另一个地方：公司特有的上下文，具体的工作流程、历史记录，还有那些不会出现在任何训练数据里的判断标准。

今年 1 月，团队里两个人用 Claude Code 和 Opus 4.6，通过 MCP（Model Context Protocol）和命令行工具接上了公司内部系统，攒出了一个数据分析 agent。不需要太多额外指导，它就能在几分钟内跨 Slack、GitHub、ClickHouse、Salesforce、PagerDuty 调查一个客户问题。原本要花一下午的工作，变成了排障和事故响应的第一步。

同样的模式延伸到调试之外。一个拿到完整上下文的 agent，能准备客户会议、研究一个账户、审阅合同或 RFP、追溯一个产品决策，把散落各处的工作变成一份成稿。但让 agent 拿到这么多上下文，本身就是新的安全和隐私风险。

Sierra 自建了一层 MCP Gateway 来解决这个问题：Pinecone 继承每个员工本人的权限，每一次工具调用都要经过策略检查，客户数据互相隔离，每一次调用都留下审计轨迹。

Sierra MCP Gateway 通过统一网关接入 37 个内部系统，每一次调用都在这里做权限检查。图片来源：Sierra 官方博客

Pinecone 构建在 Claude Code 和 Codex 之上。这两个底层工具的更新是顺风，但技术前沿一直在变，某个模型可能最擅长规划，另一个最擅长写代码，还有一个最擅长文字。把模型之上这一层攥在自己手里，团队能把每个任务路由给最合适的模型，在某个模型故障时切换，控制成本，不被单一供应商牵着走。真正留得住的优势，是拥有让每个模型都更好用的上下文、工作流和路由这一层。

agent是新界面，老系统还是那个老系统

每一份工作都会产出一个具体的东西，一个产物。写代码的 agent 最先找到了自己的产物：拉取请求（PR）。其他每个部门也有对应的产物：一份客户案例、一份合同、一份 RFP 问卷、一份路演稿、一份绩效评估。

这些产物既是 agent 干活要用的输入，也是它交出来的输出。让 Pinecone 帮忙改一版路演稿，回来的是改好的那份稿子本身，不是一句建议你这样改的聊天消息。

团队发现更好的做法，是跟这些既有的系统记录（system of record）配合，而不是取代它们。GitHub 继续保管 PR，Salesforce 继续保管客户账户，Linear 继续保管 issue，agent 是架在这些系统之上、把它们串起来的那一层。

取代这些系统，意味着要重新造一遍几十年积累下来的成熟软件。更麻烦的是，它会把公司劈成两半：一部分人通过 agent 工作，另一部分人直接在原来的工具里工作，各自留下一份不一样的记录。团队押注的方向是，这些产品会慢慢变得更像后端，agent 成为最主要的操作界面。

跑了7.5万次不代表真的变好了

Pinecone 从 3 月第一次提交代码算起，已经跑了超过 7.5 万次会话，服务 600 多名员工。如今公司 70% 的 PR 由它发起，还有数百个自动化任务在悄悄处理那些没人明确提示过的工作。

这类数字很容易被当作成绩来讲，早期阶段这样做也没错，它们证明工具真的被用起来了，不是躺在路线图的某张幻灯片上落灰。但跑了多少次会话、调用了多少次工具，这些是活动量，不是结果。一个团队完全可以把 token 用量刷得很好看，下游却什么都没变好，同样的错误率，同样的周期，只是多了 AI 参与其中。

所以 token 用量是个不错的起点，团队得先养成用这个工具的习惯，才谈得上衡量它到底有没有用。但价值不在这里，团队也不希望故事讲到这里就结束。他们想追问的是，agent 到底改变了什么：一笔交易是不是成交得更快了，一个客户的问题是不是一次就解决了，有没有人因此能准时下班，而不是又熬到深夜才做完一份评审。目前团队还没找到衡量这些的好办法，会话数和调用次数只是比较好数而已，这段差距是接下来要填的东西。

还在实验：让AI自己反思今天干得怎么样

团队正在尝试让 Pinecone 做一件新事：每天反思当天完成的工作，给自己的技能库提出改进建议。

长期看，团队想要的是一个会从 Sierra 不断学习、自我改进的 agent，而不只是一个每天替 Sierra 干完活就结束的 agent。

接下来团队还会发几篇更技术向的文章，深入拆解这套系统：Allen Chen 会讲 Pinecone 经历过的多次迭代和背后的技术架构，Mihai Parparita 会讲 MCP Gateway 如何安全地采集完整上下文，Rohith Ravi 会讲支撑这一切的底层基础设施 Agency。

从找天才，到人人都配一个

回到开头那项 1968 年的研究，它发现最好的工程师和普通工程师之间有 10 倍的产出差距。过去五十年，唯一的解法是想办法挖到那一小撮人。

现在有了另一个答案：让每个人都配一个 agent，都拥有那批人的优势。这轮变化的意义不止是把更多事情做完。它把时间腾了出来，留给那些只有人能做的部分：判断、审美、创造力，还有维系一段关系。

Sierra 把四个专属 AI 全拆了，合并成一个统一助手，叫 Pinecone。员工不用再想「该找谁」，一个入口把事从头做到尾。同时他们让它别再「问一句答一句」，而是自己盯着任务、该出手时先做一版，再交给人拍板。

但把公司这么多系统的钥匙都交给一个 AI，新麻烦跟着来了：它凭什么能安全地碰这些数据？

卡住 AI 的其实不是它不够聪明，而是它不懂你这家公司，具体流程、历史记录、只有内部人才懂的判断。Sierra 的解法是一层叫 MCP Gateway 的「权限关卡」：Pinecone 每要碰一个内部系统，都得先过这道关。

小互问一句，Pinecone 自己判断该翻哪几个系统；但每次调用都要先过 MCP Gateway，只用小互本人的权限、客户数据互相隔离、每笔都留痕。GitHub、Salesforce 这些老系统还照旧各管各的记录，Pinecone 只是罩在上面的统一入口。原本要翻一下午的排查，几分钟就出第一版。

上线四个月，数字很漂亮。先看一个具体体感：同样是排查一个客户报错，