1968 年，一项开创性研究发现了一个影响硅谷数十年的现象：最优秀的软件工程师的生产力远超同行。从此，每一家科技公司都在寻找那些能创造出非凡成果的罕见人才。
今年 1 月假期归来，我们的工程团队被前沿模型的进展所震撼，开始用 git worktrees、Claude Code 和 Codex 并行运行 Agent。在某些任务上，他们的效率提升了 5 倍。
这引出了一个更大的问题：如果 Agent 能在一个月内让工程师的生产力提升这么多，那么如何让 Sierra 的每个人都能达到这个水平？我们成立了一个六人 AI 加速小组来寻找答案。这篇博客将介绍我们构建的内容以及在这个过程中的收获。
1. 单一 Agent
我们最初构建了一组角色专属 Agent：一个支持 Agent（PINE）、一个数据分析师（Pinewood）、一个工程师（Pinecone）和一个销售 Agent（Reggie Jr）。每个角色一个 Agent 看似直观，但在实践中却行不通。
表面上看，问题在于员工需要记住哪个 Agent 负责什么，而我们偏爱松树主题的命名方式也无济于事。但更深层的问题是结构性的——最重要的工作往往跨团队完成，而非局限于团队内部。
公司的核心是一系列需要完成的任务。以产品发布为例，它涉及技术团队以及销售、市场、法务和运营部门。各部门的存在是因为一个团队或一个人无法完成所有环节。AI 改变了这一点，因为它可以越来越端到端地完成工作。
因此，我们将所有这些角色专属 Agent 合并为一个：Pinecone。它只有一个 Slack 账号、一个 URL，以及从问题到最终结果的完整连贯流程。Pinecone 会判断需要从哪些系统获取信息以及如何处理请求，员工无需操心。这在技术上很难，但正是 AI 的意义所在：技术吸收复杂性，而不是让员工来承担。
这个教训我们早已从自己的平台中学到。基于 Sierra 构建的 Agent 是全能型的：一个 Agent 可以处理从产品发现、账户设置、故障排除到账单等所有事务，而不是像老旧的 IVR 系统那样“按 1 转销售，按 2 转支持”。
将所有功能合并到一个 Agent 中，能让你更接近公司的核心价值——待完成的任务。每一次改进都能惠及整个业务，让所有人变得更好、更快。
2. 主动而非被动
大多数工作并非一次性完成。它会持续数天、数周甚至数月，期间团队不断学习、优先级调整、新信息涌现。一个只在被召唤时出现、会话结束时消失的 Agent 作用有限。Pinecone 贯穿整个流程——携带上下文，延续线程，直到任务（而非单个请求）完成。
持久性也让 Pinecone 变得主动。它无需等待被询问，当下一个步骤就绪时就能自动行动——比如某个工件触发 webhook、任务出现在 Linear 中、或收到审核请求。它会收集上下文并做初步处理，在需要人工判断时才介入。会议前，准备笔记已就绪；你还没坐下打分，面试总结已草拟完成；审核意见会附上摘要、关键风险和评论建议。目标不是增加通知，而是让未完成的工作少一些。
我们尚未完全实现这一点——大多数会话仍由人类提示开始——但逆转这种关系，让 Agent 在需要时主动提示人类，正是持久性引领我们的方向。
3. 业务上下文是瓶颈，而非智能
AI 的瓶颈曾经是原始智能——模型是否足够聪明。如今，前沿模型已能满足大多数业务需求。因此瓶颈转移到了上下文：你的公司、工作流程、历史记录以及训练数据中不包含的判断决策。
今年 1 月，我们团队中的两人用 Claude Code 和 Opus 4.6 快速搭建了一个数据分析 Agent，通过 MCP（模型上下文协议）和命令行工具连接到我们的系统。在无需额外指导的情况下，它能在几分钟内跨 Slack、GitHub、ClickHouse、Salesforce 和 PagerDuty 调查客户问题。过去需要一下午的工作，现在变成了调试和事件响应的第一步。
同样的模式远不止于调试。拥有完整上下文的 Agent 可以准备客户会议、研究账户、审核合同或 RFP、追溯产品决策，并将零散工作转化为完整的成果。当然，让 Agent 访问所有上下文也带来了新问题。不受限制的 Agent 是巨大的安全与隐私风险。我们的 MCP 网关解决了这个问题：Pinecone 继承每位员工的访问权限，在每次工具调用时执行策略，隔离客户数据，并留下审计痕迹。
读取图片描述
ALT
Sierra MCP 网关将 Agent 连接到 37 个系统
Pinecone 基于 Claude Code 和 Codex 构建。它们的频繁改进是顺风，但技术前沿不断变化——某个模型可能擅长规划，另一个擅长编码，再另一个擅长文字。拥有模型之上的层，让我们可以将每个任务路由到合适的模型，在宕机时切换，并管理成本，同时避免受制于任何单一厂商。但持久优势不在于拥有底层模型，而在于拥有上下文、工作流和路由层，从而让每个模型都更有用。
我们也在尝试让 Pinecone 自我反思：每天回顾工作，并为自己的技能提出改进建议。随着时间的推移，这将区分出一个仅为 Sierra 工作的 Agent 与一个能从 Sierra 中学习的 Agent。
4. Agent 即 UI，记录系统即后端
每项工作都会产生具体的成果——工件。编码 Agent 最先发现了它们：Pull Request。其他部门也有各自的对应物——客户案例、合同、RFP 问卷、演示文稿、绩效评估。
工件既是输入也是输出。它们为 Agent 提供完成工作所需的上下文，同时也是最终成果的归宿。让 Pinecone 优化演示文稿，返回的是更新后的文稿本身，而不是一条告诉你该改什么的聊天消息。
我们发现，最好与现有的记录系统协作，而不是取代它们。GitHub 保留 PR，Salesforce 保留账户，Linear 保留任务——Agent 是贯穿这些系统的层。
取代这些系统意味着要重建几十年来成熟的软件。更糟的是，它会让公司分裂成两个阵营——通过 Agent 工作的人和直接在原始工具中工作的人，各自拥有不同的真相版本。我们的判断是，这些产品会逐渐演变为后端，而 Agent 将成为主要界面。
5. 成果，而非活动
自 3 月首次提交以来，Pinecone 已为 600 多人运行了超过 75,000 次会话。如今，我们 70% 的 PR 通过它创建，同时数百个自动化程序默默处理着无人明确提示的工作。
这样的数字很诱人，在早期也确实值得追踪——它们证明有东西在被实际使用，而不是躺在路线图幻灯片上积灰。但会话运行和工具调用是活动，而非成果。一个团队可以刷出漂亮的采用率图表，而下游实际情况毫无改善——同样的错误数量，同样的周期时间，只是多了 AI 参与。
因此，Token 使用量是一个不错的起点。团队需要先养成使用工具的习惯，然后才能衡量它是否有效。但这并非价值所在，我们也不希望故事就此结束。我们努力想提出的问题不是 Agent 做了多少事，而是它真正改变了什么：交易是否更快完成？客户问题是否一次解决？是否有人因此省下了熬夜审阅的时间？
我们还没有好的方法来衡量这些。会话和工具调用只是更容易计数。但可衡量的东西与我们真正关心的东西之间的差距，正是我们接下来要构建的方向。
1968 年的那项研究发现，顶尖与普通之间存在 10 倍的差距，而五十年来唯一的答案就是去寻找那些罕见的人才。现在有了更好的方案：给每个人配备一个 Agent，让他们拥有少数人的优势。目标不仅仅是完成更多工作，而是让人们有更多时间去做只有人才能做的事情：判断、品味、创造力以及建立关系。
接下来
我们将深入探讨所构建的系统：
- Allen Chen 关于 Pinecone、其多次迭代以及背后的技术架构
- Mihai Parparita 关于 MCP 网关及安全获取完整上下文
- Rohith Ravi 关于 Agency 及其底层基础设施
