Bold.org 内部公司 Agent 搭建复盘：做对的五件事与五个教训

在我最近关于 AI 工程配置的文章中，我简要说明了 Bold.org 的一个可观测性项目如何演变成了一个公司内部智能体。

简而言之，2026 年 1 月时，Bold.org 已经在 ClickHouse 中存储了结构化的后端事件，工程师可以用 SQL 来调查这些事件，而我想看看智能体是否也能做到同样的事。它成功了，于是我便不断接入更多公司系统。几周之内，Bold.org 各处的人都在使用它。它最终在工程、产品、支持、运营、市场和增长等各个领域都变得有用。

这样的总结让这条路径听起来比实际顺利得多。

有几个决策帮助这个智能体迅速传播开来。我也花时间解决了一些我其实并不存在的问题，把一些重要问题拖得太晚，还误以为一些事情显而易见，而它们显然并非如此。

这不是一份构建智能体的通用指南。这是一份来自在真实公司内部构建智能体的实践回顾：我们做对的五件事，以及今天我会以不同方式处理的五件事。

这在实践中是什么样子

第一个工作流很直接：我给了智能体对 ClickHouse 中结构化后端事件的只读访问权限，这样它就能调查生产环境的问题。随后我又接入了更多人们已经在使用的系统，包括 Slack、Linear、PostHog 和 Grafana。

实际效果远不止是更快地编写 SQL。支持团队可以自主调查许多客户报告，无需等待工程或其他团队提供背景信息。对于我们针对的工作流，过去需要数小时、还要通过三四个找到合适权限的人才能完成的调查，现在通常可以在零到一小时内完成。智能体还能自动完成 PostHog 和 Grafana 中部分仪表盘设置和分析工作，无需工程介入。

该系统每月消耗数十亿个 token。这使得使用分析和成本意识变得很重要，但它也是一个有用的信号，表明这个工具已经成为人们工作方式的一部分，而不是一个偶尔打开的演示。

我刻意让一个安全边界保持简单。智能体通过我们公司域名的 Google 登录进行访问控制，并且它的所有远程访问都是只读的。与其依赖模型来判断何时变更是安全的，我干脆一开始就没有给它写入远程系统的权限。

哪些做法有效

1. 尽早让使用情况可见

所谓“可见”，我指的是在公司内部可见。

人们很容易私下构建一个内部工具，让它感觉完整，写一份公告，然后请大家使用它。我们做的几乎相反。这个智能体在共享的 Slack 频道中使用，并接入了 Linear，人们本来就在那里工作，可以看到它做了什么。

这比任何发布文档都更重要。

大多数人不会立刻知道智能体能做什么。一个空白的聊天框并不能说明它的能力。即使有一份很好的示例列表，也仍然需要有人把这些示例转化到自己的工作中。

看到真实的使用情况就能解决这个问题。有人在 Slack 中提问，智能体进行调查，另外十个人既看到了结果，也看到了提问的方式。一位产品经理注意到它可以检查用户流程。支持团队的某个人意识到它可以帮助调查一份报告。一位工程师看到它收集了自己本来要手动收集的背景信息。

每个可见的交互都基于真实的公司问题，成为一个小型产品演示。

Slack 和 Linear 之所以重要还有另一个原因：它们不需要人们去适应一个新的目的地。如果是另一个内部 Web 应用，就等于要求每个人都记住这个工具的存在、打开它，并决定何时使用它。而在 Slack 和 Linear 中，智能体出现在问题或任务已经存在的地方。

Web 界面仍然有用，尤其是在处理私密或较长的工作时。但正是共享使用让公司认识到了什么是可能的。

2. 连接公司已经在使用的工具

当我在一月份开始做这件事时，MCP 还处于起步阶段，我们需要的许多系统还没有可用的服务器。我用小型 CLI 工具填补了这一空白，这些工具大多是对 OpenAPI 端点或现有 SDK 的轻量封装，只暴露我们工作流所需的操作。它们刻意做得很朴素：结构化结果、狭窄的权限、正确的错误处理，以及让凭证远离模型。

其价值不仅仅在于智能体能多执行一个操作。更多的访问权限意味着更多的公司上下文：生产数据、工单、分析、仪表盘和运营信息可以被一起考虑。这让智能体在推理时有了更好的依据，也使其回答比从单一系统推断出的任何内容都更有用。

3. 追踪人们实际如何使用它

使用分析很早就接入了。不是为了创建排行榜，也不是为了衡量谁在正确地“做 AI”，而是为了了解已经构建了什么。

工具调用、token 消耗、重复出现的工作流以及广泛的使用模式，显示了哪些工具有价值、哪些请求正在变得昂贵，以及人们一直试图使用哪些能力。这使得基于行为而非猜测来改进产品成为可能：意外的使用表明某个工作流需要简化，而未被使用的工具则指向可发现性差、描述不佳或价值有限。聚合的运营指标比给个人排名更有用，也让分析专注于改进工具，而不是监控员工。

4. 闭合反馈循环

人们会尝试你未曾预料到的事情。他们也会遇到在系统构建者看来显而易见、却令人困惑的行为。

反馈很容易分享，智能体也随着人们的使用而调整。这听起来很基础，但它创造了一个有用的循环：有人尝试了某个工作流，报告了失败之处，之后往往很快就能试用改进后的版本。

这种响应性鼓励了更多实验。当人们知道失败不是对话的终点时，他们会更愿意探索新工具。

一些基础文档也有帮助。它不需要解释每一个工具，也不需要成为完整的 AI 培训课程。简短说明智能体能访问什么、好请求的示例、已知限制以及如何分享反馈，就足以让人们有信心开始。

这种组合很重要。没有反馈的文档会变得过时。没有文档的反馈意味着永远在回答同样的入门问题。

5. 为整个公司而设计

这个智能体最初源于工程和可观测性问题，所以让它专注于工程师本会是显而易见的路径。但那会是一个错误。

一些最有意思的用法来自产品、支持、运营、营销和增长团队。这些团队往往需要跨多个系统获取信息，却没有便捷的方式来查询或整合这些信息。一个拥有恰当公司上下文的智能体可以省去大量来回查找的麻烦。在支持团队中，这一点尤其强大：人们可以自行调查许多报告，而不必等待工程团队去收集上下文。

工程师实际上可能更难被说服。

他们已经有编码智能体、终端工作流、偏好的模型、自定义指令，以及对工具链的强烈主见。要求他们迁移到一个共享的公司界面，感觉就像要求他们放弃花了几个月打磨好的配置。我理解这种抵触，因为我对自己使用的工具也有同样的看法。

其他部门可能没有那么多现成的智能体工作流需要替换。一旦他们看到一个相关的示例并信任了访问模型，价值就能更快显现。

把智能体当作公司基础设施而非工程实验，既改变了它的采用情况，也改变了哪些功能最重要。

我会做出改变的五件事

1. 更早设计本地访问

最大的缺失环节是让公司工具能够从本地智能体工具链中安全地使用。

共享的 Web、Slack 和 Linear 界面很有用，但本地智能体拥有公司智能体所不具备的上下文。它们可以处理个人的文件、笔记、项目记忆、终端和当前代码库。尤其是工程师，他们不希望每次需要公司信息时都放弃这些上下文。

理想的方案不是强迫所有人使用同一个工具链，而是允许经过批准的本地工具链使用公司工具，同时不暴露凭据、不绕过权限。

这比再增加一个界面要难得多。身份验证需要代表发起请求的人。密钥不能交给本地模型。工具访问应保持限定范围且可审计。一个被攻破或配置不当的本地环境不应获得广泛的公司访问权限。

2. 少花时间追求完美架构

智能体工具链变化不断。框架层出不穷，模型不断改进，MCP 约定持续演进，每周都有关于 AI 应该是什么、应该如何构建、哪些模式或用例对或错的新观点。

人们很容易围绕网上大家都在讨论的东西不断重新设计系统。

我花了太多时间考虑是否应该围绕最新方法重建智能体的某些部分。这些思考大多保质期很短：一个月前看起来必不可少的工具或模式，几个月后可能就无关紧要了。如今我会选择一个支持当前用例的简单架构，然后向前推进。保持连接器小巧，保持边界清晰，避免把所有东西都耦合到某一个模型或框架上，只在有真正理由时才替换组件，而不是因为某个新架构图在社交媒体上流行。

内部工具在这方面有优势：它们不需要成为面向所有可能客户的通用平台。它们需要解决公司的实际问题。

3. 让贡献路径清晰可见

智能体进步很快，但其中太多改进依赖于少数几个人。

谁能编写技能、添加连接器、改进指令或贡献代码，这一点并不明显。即使代码仓库可用，人们也有理由犹豫。Agent 系统结合了代码、提示词、权限和不熟悉的约定。没人想弄坏公司范围内使用的工具，或意外泄露敏感信息。

我还没有解决这个问题。欢迎大家使用这个 agent，但如何安全地做出贡献并不明显。代码仓库是开放的，但编写技能、添加连接器或修改指令，都需要理解代码、提示词、权限和不熟悉的约定。

一份简短的贡献指南，包含示例、归属、审查要求和安全的测试路径，会让这件事更容易。在那之前，太多的改进都依赖于少数几个人。

4. 少构建一些评估和追踪基础设施

我在评估、详细追踪和比较模型行为上花了太多时间。一定的可见性是必要的：足够的追踪来调试故障，使用分析来控制开销，以及对关键工具和权限的测试。但这里不是前沿实验室，也不是有专门评估团队的产品。它是一个内部工具，我不能把所有时间都花在为假设的故障构建基础设施上。

目标是让它简单、让它能用、让它可维护。几个有代表性的工作流和权限测试就足够了，直到反复出现的故障证明需要更多。评估系统应该从真实问题中成长，而不是出于对衡量不足的恐惧。

5. 少假设别人已有的 AI 知识

最大的错误可能是假设对我来说显而易见的能力，对其他人也显而易见。

AI 的采用在不同部门和个人之间差异巨大。有些人整天与 agent 打交道。另一些人只用过基础的 ChatGPT 界面。工具、记忆、连接器、上下文或技能这些术语对他们可能毫无意义，而他们本就没有理由应该懂。

从构建者的角度看，好处似乎很明显：agent 可以搜索多个公司系统，整合找到的内容，并据此采取行动。从别人的角度看，它可能只是另一个聊天框。为什么要用它而不是 ChatGPT？它知道什么？它能做什么？问什么是安全的？它会在未经许可的情况下做出更改吗？

我也还没有完全解决这个问题。

最有帮助的是把抽象的能力变成可见的功能。不要宣布 agent 有了一个新连接器。要展示它能准备一份具体的报告、调查一类已知问题，或自动化一个重复的工作流。给人们一些相关的、可以立即尝试的东西。

采用不会因为架构令人印象深刻而发生。它发生在有人看到 agent 解决了他们能认出的问题时。

主要教训

这些是前六个月的主要教训和错误：尽早让 agent 可见，把它连接到上下文所在的系统，保持访问安全，并针对简单到足以维护的东西进行优化。

最好的决定是让人们在这个 agent 感觉完成之前就看到它被使用。反复出现的教训是，对构建者来说显而易见的东西，对其他人来说很少是显而易见的。

我很想了解其他团队在实践中是如何采用 AI 的，哪些做法行之有效，以及哪些工作流程仍然别扭，或因访问权限、上下文或信任问题而受阻。如果你也在思考类似的问题，或在团队或公司中引入 AI 原生工作流程时遇到挑战，我很想了解更多，并看看我是否能帮上忙。