Sierra 全员用 AI 智能体 Pinecone 的五条经验

1968年，一项开创性研究发现了将影响硅谷数十年的现象：最优秀的软件工程师的生产力远超同行。自那以后，每一家科技公司都在寻找那些能够创造非凡成果的稀缺人才。

一月份休假归来后，受前沿模型进展的启发，我们的工程团队开始使用 git worktrees、Claude Code 和 Codex 并行运行智能体。在某些任务上，他们的完成量提升了 5 倍。

这引出了一个更大的问题：如果智能体能让工程师在一个月内生产力提升如此之多，那么要让 Sierra 的每个人都达到这一水平，需要做些什么？我们成立了一个六人 AI 加速团队来寻找答案。这篇博客介绍了我们构建了什么，以及在这个过程中学到了什么。

1. 单一智能体

我们从一组按角色划分的智能体开始：一个支持智能体（PINE）、一个数据分析师（Pinewood）、一个工程师（Pinecone）和一个销售智能体（Reggie Jr）。每个角色一个智能体看似直观，但在实践中失败了。

表面上看，问题在于员工的负担——他们必须记住哪个智能体做什么。我们对松树主题名字的喜爱也没帮上忙。但更深层的问题是结构性的——最重要的工作发生在跨团队之间，而非团队内部。

从本质上讲，公司是一系列待完成工作的集合。以交付产品为例，它涉及技术团队以及销售、市场、法务和运营。部门之所以存在，是因为一个团队或一个人无法完成工作的每一个部分。AI 改变了这一点，因为它越来越能够端到端地完成工作。

因此，我们将所有这些按角色划分的智能体合并为 Pinecone：一个单一的智能体，拥有一个 Slack 账号、一个 URL，以及从提问到完成结果的一条不间断线程。Pinecone 会自行判断从哪些系统获取信息，以及如何处理请求，这样员工就不必操心这些。这在技术上很难，但这正是 AI 的意义所在：技术吸收复杂性，而不是让员工承担。

这是我们在自己的平台上已经学到的教训。在 Sierra 上构建的智能体是全方位的：一个智能体可以处理从产品发现到账户设置、故障排除、计费等一切事务。而不是像老式 IVR 那样“按 1 转销售，按 2 转支持”。

将所有功能合并到一个智能体中，能让你更接近公司价值的所在——待完成的工作。每一项改进都惠及整个业务，因此每个人都能变得更好、更快。

2. 主动而非被动

大多数工作不是一次就能完成的。它会持续数天、数周甚至数月，随着团队学习、优先级变化和新信息的出现而展开。一个在提示时出现、在会话结束时消失的智能体，作用有限。Pinecone 贯穿整个过程——携带上下文向前推进，重新拾起线索，直到工作（而不仅仅是个别请求）完成。

持久性也让 Pinecone 变得主动。它不必等待被询问，而是在下一步准备就绪时采取行动——某个产物触发了 webhook、Linear 中出现了任务、收到了评审意见。它收集上下文并进行初步处理，在需要人类判断时引入人员。会议前准备笔记已经就绪。面试复盘在你坐下来添加评分之前就已起草。评审意见附带摘要、关键风险和建议评论。目标不是更多的通知，而是更少未完成的工作。

我们还没有完全把这件事敲定——大多数会话仍然以人类提示开始——但反转这种关系，让智能体在需要时提示人类，正是持久化的发展方向。

3. 业务上下文是瓶颈，而非智能

AI 的瓶颈曾是原始智能——模型是否足够聪明。如今，前沿模型对大多数业务需求而言已足够强大。因此瓶颈转移到了上下文：你公司特有的东西、你的工作流、你的历史，以及那些不会出现在任何训练集中的判断决策。

今年一月，我们团队的两个人用 Claude Code 和 Opus 4.6 拼凑出了一个数据分析智能体，通过 Model Context Protocol（MCP）和命令行工具连接到我们的系统。无需太多额外指导，它就能在几分钟内跨 Slack、GitHub、ClickHouse、Salesforce 和 PagerDuty 调查客户问题。曾经耗费一下午的工作，变成了调试和事件响应的第一步。

同样的模式远不止于调试。拥有完整上下文的智能体可以准备客户会议、研究客户账户、审阅合同或 RFP、追溯产品决策，并将零散的工作转化为成品。当然，让智能体访问所有这些上下文会带来一个新问题。不受限制的智能体是巨大的安全和隐私风险。我们的 MCP Gateway 解决了这个问题：Pinecone 继承每位员工的访问权限，在每次工具调用时执行策略，隔离客户数据，并留下审计轨迹。

Pinecone 构建在 Claude Code 和 Codex 之上。它们的频繁改进是一股顺风，但最先进的技术不断变化——一个模型可能最擅长规划，另一个最擅长编码，还有一个最擅长写作。拥有模型之上的那一层，让我们能够将每项任务路由到正确的模型，在停机时故障转移，并管理成本，同时避免受制于任何单一玩家。但持久的优势不在于拥有底层模型，而在于拥有让每个模型更有用的上下文、工作流和路由层。

我们还在尝试让 Pinecone 做梦：反思每天的工作，并提出改进自身技能的建议。随着时间的推移，这就是一个只为 Sierra 工作的智能体和一个从 Sierra 学习的智能体之间的区别。

4. 智能体是 UI，记录系统是后端

每一项工作都会产生具体的东西，一个产物。编码智能体最先找到了它们的产物：拉取请求。其他每个部门都有自己的对应物——客户故事、合同、RFP 问卷、路演幻灯片、绩效评估。

产物既是输入也是输出。它们为智能体提供完成工作所需的上下文——也是完成工作所属的地方。让 Pinecone 收紧一份路演幻灯片，返回的是更新后的幻灯片本身，而不是一条告诉你该改什么的聊天消息。

我们发现最好与你的记录系统协作，而不是取代它们。GitHub 保留 PR，Salesforce 保留账户，Linear 保留问题——智能体是横跨它们的层。

取代这些系统意味着重建数十年成熟的软件。更糟的是，它会把公司一分为二——通过智能体工作的人和直接在原始工具中工作的人，各自拥有自己的事实版本。我们赌的是，这些产品会随着时间推移变得更像后端，而智能体成为主要界面。

5. 结果，而不仅仅是活动

自 Pinecone 在三月完成首次提交以来，它已为 600 多人运行了超过 75,000 个会话。如今，我们 70% 的 PR 都是通过它发起的，同时还有数百个自动化流程在默默处理着无人明确要求的工作。

这样的数字很容易让人想拿来当开场白，而且在早期，它们确实是该追踪的指标——它们证明某样东西真的在被使用，而不是躺在路线图幻灯片上积灰。但会话数和工具调用次数只是活动量，不是成果。一个团队可以靠堆 token 堆出一张看起来很漂亮的采用率图表，而下游却没有任何实际改善——错误数量一样，周期时间一样，只是有更多 AI 参与制造了它们。

所以 token 用量是个不错的起点。团队需要先养成使用工具的习惯，然后才能衡量它是否奏效。但价值并不在这里，我们也不希望故事到此为止。我们正努力更擅长提出的问题，不是智能体做了多少事，而是因为它，究竟什么发生了改变：一笔交易是否更快成交，客户的问题是否一次就解决，某人是否找回了自己的夜晚，而不是熬夜到深夜才完成一次评审。

我们目前还没有好的方法来衡量这一点。会话数和工具调用次数只是更容易统计。但今天我们能衡量的与我们真正关心的之间的这道鸿沟，正是我们接下来要努力构建的方向。

1968 年的那项研究发现，最优秀者与其余人之间存在 10 倍的差距——五十年来，唯一的答案就是去寻找那些稀有的人才。现在有了更好的办法：给每个人一个智能体，让他们拥有少数人才有的优势。目标不只是完成更多工作，而是让人们有更多时间去做只有人才能做的工作：判断力、品味、创造力，以及建立关系。

接下来

我们将深入介绍我们构建的系统：

• Allen Chen 谈 Pinecone、它的多次迭代以及背后的技术架构
• Mihai Parparita 谈 MCP Gateway 以及如何安全地收集完整上下文
• Rohith Ravi 谈 Agency，以及支撑这一切的基础设施