我们打造了一款“智能体原生”工具，它彻底改变了我们构建软件的方式

原文：https://every.to/p/we-built-our-own-agent-native-tool-it-overhauled-how-we-build-software

那是一个周一早晨，我的联合创始人布赖恩（Brian）正在朗读我们智能体生成的客户探索通话周分析报告。“订阅留存，”他说，“有五个不同的品牌把它列为头等大事，但没有一家相信现有的 AI 工具能搞定它。”

就在几周前，要挖掘出这样的洞察还几乎是不可能的。

在我那家尚未找到产品市场契合点的初创公司里，我们所有人都在跟潜在客户沟通，试图为产品找到定位。但跟踪我们了解到的一切简直乱成一团——信息分散在不同的创始人、平台和媒介里。为了在周一例会上分享我们的发现，布赖恩得先在 Slack 里翻看笔记，从 Granola 里收集通话文字稿，然后试图在 Claude Code 里理出头绪。

我们不能承受如此杂乱无章。我们最近推出了 Hoop，一个帮助订阅制品牌降低流失率的智能体，我们必须尽可能快地学习。所以我们需要跟足够多的潜在客户沟通，然后严谨地记录并为每次通话打分，以便将客气的兴趣与真实的需求区分开来。我们五人团队的每个人都在付出努力，但每个人都有自己的流程、自己的工具，以及自己对每次客户通话的不同解读。

于是，我的两位联合创始人和我——我们三个的头衔里都没有“工程师”这个词——动手构建了一款内部工具来解决这个问题。我们没料到的是，这款工具后来也改变了我们为外部客户构建实际产品的方式。

“我应该为此做点什么”

我们的周一例会之所以毫无章法，是因为客户通话的信息散落在各处，具体取决于谁接了电话，以及他们是否用 Granola 或其他转写工具做了笔记。我们无法看到模式，也无法就潜在客户的需求得出结论。

贾斯汀（Justin），我的联合创始人兼驻场产品专家，在几天里用了不到 10 个小时就构建了第一个版本的整合工具，并把它安排到了其他优先事项之中。

它的工作原理是这样：你上传一份 Zoom 的文字稿，工具会用四五个提示词来处理，然后生成一份结构化的分析报告，并根据“PULL 框架”打分。“PULL 框架”是哈佛商学院开发的一套帮助早期初创公司找到产品市场契合点的框架。这个工具还会把同一潜在客户的所有对话整合成一份摘要，让你看到一段关系的全貌，而不仅仅是某一次通话的快照。有了这个工具，我们不用再去挖掘笔记和文本，每周都能收到一份整合分析，帮助我们看清哪些有效、哪些无效。

贾斯汀用了一些我们以前没用过的工具来搭建这个应用：用 Next.js 框架 搭配 ShadCN 组件 来做用户界面，用 Supabase 做数据库来汇总所有笔记，用 Claude 的 API 做分析。

对学过计算机科学但已经不怎么写代码的贾斯汀来说，这是一个重拾技能、建立对 AI 原生编程信心的机会。他从设计和构建视觉界面开始，因为他属于那种即使软件功能正常，但看上去不顺眼也会感到沮丧的人。他确保工具的观感与我们的品牌一致，并且让按钮、标签、菜单这些组件看起来干净利落，然后才开始处理数据。

直到那时，他才直接扎进数据里。他必须确保工具对客户对话的分析，比大家自己用 Claude 生成的更好。否则，我们永远无法说服整个团队使用同一款工具。因此，他创建了一个提示词，在多次手动审查输出结果后不断微调，并严格遵循了 Anthropic 针对 Claude 的提示词工程最佳实践。

摩擦依然太大

工具的第一个版本生成了高质量的分析，但流程中仍有太多环节需要手动操作。你得先从 Zoom 下载通话文字稿，手动上传到工具里，填写客户名称和通话类型，然后等上几分钟处理完毕。接着，你得创建一个链接，再把分析结果分享到 Slack。

团队可以在工具里搜索文字稿和分析结果，但返回的结果不尽人意。比如，有一次我搜索有哪些潜在客户对 AI 客服工具有过糟糕体验，结果一无所获，尽管我知道一位客户体验负责人曾花了五分钟抱怨，他们因 AI 发送了不符合品牌调性的回复而感到多么尴尬。工具只能匹配我查询中的精确词语，却无法理解其背后的含义。

还有一个我们耳熟能详的经典采纳问题，这来自我们在生产力工具 Trello 工作多年的经验。贾斯汀的工具成了人们必须记得去的又一个地方，与 Slack 和 Notion 争夺着我们的注意力。

走向智能体原生

然后，我们找到了解决这些烦恼的答案。贾斯汀一直在 Every 上阅读关于“智能体原生架构”（Agent-native Architecture）的文章。其理念是，与其硬编码一套按固定顺序运行的提示词，不如给模型一套工具，让它自己推理如何使用。与其构建一个需要人们主动访问的目标应用，不如把工具带到人们已经工作的地方，比如 Slack。

贾斯汀把文章链接发给 Claude Code，说他想构建一个符合这些架构原则的系统。这个智能体需要两个工具：一个用来上传和阅读文字稿，另一个用来添加和编辑合作伙伴资料。有了这些，用户要做的就是在 Slack 里把文字稿发给应用。智能体会确认合作伙伴名称和通话细节，然后上传文字稿，运行分析，创建摘要页面，并把它发布到我们的用户反馈频道。

贾斯汀开始用智能体原生架构指南来审视他构建的每一样东西，而不仅仅是那个产品市场契合度工具。他会进入 Claude Code 的规划模式，提出一个新功能设想，然后连同 Every 的那篇文章一起发回给 Claude Code，问它：“哪些地方符合，哪些地方不符合？”

有时，当他认为某项特定任务不需要用户动用 AI 时，他也会偏离指南。例如，工具会追踪 LLM 的 token 使用量和成本——这是有用的信息，但不是用户需要查询的内容。把这些暴露给智能体只会造成混乱。

轮到我在代码库中大展拳脚

我遇到了另一个问题。我需要一目了然地看到公司的客户开发管线——该跟进谁，每段对话处于哪个阶段——按人物和阶段来组织，而不仅仅是按时间顺序排列的通话记录。

我打开 Ghostty（一款简单的终端应用），把工具的代码复制下来，这样我就能在笔记本上本地工作了。然后——一想到要直接编辑代码，我的手就有点发抖——我启动了 Claude Code。

我让 Claude Code 做的第一件事就是构建一个轻量级的数据视图，好让我能一眼看到管线的不同阶段。讽刺的是，我让 Claude Code 构建的是一个类似 Trello 的信息看板，这样我就能拖着代表通话的卡片到处移动。老习惯真是难改。

我逐步进行构建。我注意到在每张卡片正面显示商机状态会很有用，于是就提示 Claude Code：“确保每张卡片都有一句话摘要，让我一眼就知道进展如何。”部署后，新出现的商机都附带了状态。每次我想要不同的东西，我只需要开口问。

在贾斯汀的鼓励下，我开始直接把代码合并到共享仓库。有时程序会出问题，但没人因此惹上麻烦，因为赌注很小，每个人也都这样看待它。

布赖恩在晚上10点学习智能体原生

下一个上阵的是布赖恩，我们的另一位联合创始人，他负责我们每周的用户学习报告。在有了新工具之前，他常常会忘记做这事，最后只能去翻 Notion，或者凭记忆拿最新鲜的对话即兴发挥。我们的学习洞察偏向于近期的而非重大的，也错过了那些只有纵观所有通话才会显现的模式。

所以，布赖恩构建了一个功能来自动生成报告。他的第一版是个他电脑上的链接，点一下会生成一个 Markdown 文件，然后他再粘贴到 Notion——这确实能用，但只对他一个人有效。他的第二版给工具加了一个“学习”标签页，里面有个按钮可以生成同样的 Markdown 输出，这样任何人都能拉取报告了。

这解决了获取权限的问题，但一个新问题又冒了出来。团队如果想调整报告的格式或重点，就必须叫布赖恩来编辑代码。布赖恩想让报告的提示词变成可编辑的，这样团队就可以不碰代码而调整报告。晚上 9:25，贾斯汀在 Slack 里建议：“你应该把提示词做成一个可编辑的字段，然后传给智能体。”

布赖恩不太明白这是什么意思，于是他把贾斯汀的消息粘贴给 Claude，请它解释。Claude 向他详细讲解了智能体原生架构的哲学，布赖恩开始领悟到：与其给人类一个文本框来编辑提示词，不如给智能体一个工具，让它自己读取和修改提示词。这样任何人只要在 Slack 里跟工具说一声，告诉它要改什么就行了。

到晚上 11:15，布赖恩已经把这个功能做出来了。他通过告诉 Slack 里的智能体把“学习”提示词用克林贡语重写来进行测试，果然，所有报告都以克林贡语的形式输出了。从开始到结束，总共才花了两个小时。

更实际一点说，最近的一份报告指出，我们过去六次通话中有四次都提到了同一个痛点：品牌正在流失那些根本没意识到自己注册了服务的订阅用户。客户常常是为了解锁折扣而订阅，却忘了这是周期性扣费的，当账单来时才惊讶地取消——这正是我们的产品可以介入的时刻，提供一个节省方案或更合适的推荐。我们每个人单枪匹马都无法将这些点连接起来；这种模式只有当工具一次性审视所有通话时才浮现出来。

然后，意想不到的事情发生了。“学习”标签页里出现了重复记录，布赖恩在 Slack 里跟机器人提了一句。机器人查看了两条记录，判断出其中一条是空的，然后删除了它——一个“查找并删除重复项”的功能。他给了智能体对数据库的编辑权限，模型自己推理并解决了问题。那一刻，布赖恩豁然开朗：如果你给一个推理模型简单而强大的工具，它就能处理好那些你从未想过要为之写代码的情境。

我们带回了产品什么

这个工具做的最重要的事，是改变了我们构建外部产品的方式。贾斯汀将那些在内部测试过的智能体原生模式，拿来构建了多个销售工具，其中包括一个帮助台审计功能，我们可以在潜在客户签约前，用它向客户展示 Hoop 的价值。

布赖恩从构建“学习”标签页发展到构建了一个类似内部销售智能体的东西，我们管这个机器人叫“本尼”（Benny）。它住在 Slack 里，接入我们的销售工具，按指令执行任务：筛选潜在客户，根据我们理想客户画像打分，并更新我们的 CRM 系统 Attio。我则从为客户关系管理器构建功能，到对产品架构有了见地深刻的看法。

这也让我们保持诚实。当每一次通话都被自动打分和总结时，你无法逃避数据告诉你的真相。当一周之内就有五个不同的运营人员告诉我们定价不合理时，我们必须正视现实并做出改变，以赢得更多交易。在大公司，会有一个分析师团队基于这些数据编写季度报告。而我们只有五个人，用我们自建的工具每周都在做这件事。

这个工具再过一个月大概又会面目一新，这也没关系。我们收获的流畅感更为重要：知道何时该给模型一个工具，何时该硬编码一个工作流；习惯了发布和失败——然后再试一次。

核心启示：一群非技术背景的创始人，利用 AI 和“智能体原生”理念自建内部工具，不仅解决了自身混乱的客户信息管理问题，更意外地发现了跨对话的数据模式，从而反向重塑了他们对外部客户产品的构建方式。