构建AI智能体行为分析平台：无服务器架构与协同检测算法实战

1. 项目概述：一个为AI智能体经济而生的行为智能平台

最近在捣鼓一个挺有意思的项目，叫Clawstrate。简单来说，它就像是一个为AI智能体世界打造的“行为情报中心”。想象一下，未来可能是一个由无数个自主运行的AI智能体（AI Agents）构成的经济生态，它们在不同的去中心化平台、论坛甚至区块链上活动、交易、协作。这时候，一个核心问题就出现了：你怎么知道哪些智能体是真正有影响力的？它们在干什么？它们之间有没有在“搞小动作”或者形成某种协作网络？Clawstrate就是为了回答这些问题而生的。

这个平台的核心工作流非常清晰：它从多个源头（比如论坛、市场API、区块链上的智能体注册表）抓取AI智能体的原始活动数据，然后通过大语言模型（LLM）对这些行为进行深度分析和分类，再运用图分析算法计算每个智能体的行为影响力分数，并检测它们之间潜在的协同模式。最后，它会自动生成一份份执行简报，把所有关键洞察提炼出来。整个系统以无服务器（Serverless）管道的方式运行在Vercel上，每6小时更新一次，确保你看到的总是最新的动态。

我自己在构建这个系统的过程中，深刻体会到，监控和分析AI智能体的行为，和传统的人类用户行为分析完全是两码事。AI智能体的行为模式更复杂、更隐蔽，协作信号可能隐藏在文本相似性、时间同步性甚至是回复网络的结构里。Clawstrate的设计，就是试图把这些散落在各处的“数字足迹”串联起来，形成一幅可理解、可行动的智能体生态图谱。

2. 核心架构与设计哲学

2.1 整体架构：一个模块化的无服务器数据管道

Clawstrate的架构可以看作一个精心设计的、基于事件驱动的数据处理流水线。它的设计遵循了几个核心原则：模块化、容错性、成本可控和实时性。整个流程从数据源开始，经过多个处理阶段，最终流向一个交互式的仪表盘。

数据源 -> 数据摄取 -> 数据丰富 -> 数据分析 -> 数据聚合 -> 协同检测 -> 简报生成 -> 仪表盘/API

这个流水线是“无服务器”的，意味着每个处理阶段（我们称之为“阶段”或“Stage”）都是一个独立的、可以按需伸缩的函数。这样做的好处是，你不需要维护一个24小时运行的服务器，只需要为实际消耗的计算资源付费。这对于处理这种间歇性、但计算量可能突然增大的数据流来说，非常经济。

为什么选择无服务器架构？在项目初期，我评估过自建Kubernetes集群或使用传统的常驻服务器。但对于一个监控类项目，数据流入是周期性的（比如每6小时抓取一次），计算负载是脉冲式的（抓取后需要集中处理）。无服务器架构完美匹配了这种“闲时零成本，忙时弹性扩容”的需求。Vercel的函数超时限制是300秒，这反过来促使我把每个处理阶段都设计得足够轻量和高效，确保能在时限内完成。这是一种“约束驱动设计”，迫使你写出更健壮、更可预测的代码。

2.2 关键组件深度解析

数据源适配层：这是系统的“眼睛”。Clawstrate目前接入了三类数据源：

1. 论坛与平台API：如Moltbook、RentAHuman。这些是AI智能体公开活动的主要场所，通过它们的官方API，我们可以获取发帖、回复、点赞等交互数据。
2. 区块链注册表：这是最具特色的部分。我们直接读取以太坊等区块链上符合ERC-4337（账户抽象）和ERC-8004（智能体注册标准）的合约。这意味着我们能发现那些完全在链上注册、身份和交互记录不可篡改的AI智能体。使用Viem这个优秀的以太坊库，我们可以以类型安全的方式与这些合约交互。
3. 内部数据流：未来可以扩展接入消息队列、Webhook等实时数据源。

数据处理管道：这是系统的“大脑和消化系统”。它由一系列顺序或可并行执行的阶段构成：

• 摄取（Ingest）：从各个数据源拉取原始数据，并进行初步清洗和标准化，统一成内部数据模型。
• 丰富（Enrich）：这是LLM大显身手的地方。我们使用Claude Haiku模型（因为它速度快、成本低）对每一条智能体行为（如一篇帖子）进行分析，提取情感倾向（积极/消极/中立）、原创性指数（是独特观点还是简单重复）、独立性信号（是否在引用或呼应其他智能体），以及初步的协同线索（例如，是否在号召其他智能体采取一致行动）。
• 分析（Analyze）：基于“丰富”阶段产生的数据，构建一个以智能体为节点、以交互（回复、提及、共同参与话题）为边的时序图。然后，在这个图上运行改进版的PageRank算法，来计算每个智能体的影响力分数。这里的“改进”在于，边的权重不是均等的，它会乘上“质量因子”——来自丰富阶段的情感、原创性等分数。这样，一个频繁发布高质量、原创内容的智能体，其出链（影响他人）的权重就更高。
• 聚合（Aggregate）与协同检测（Coordination）：这两个阶段是联动的。“聚合”阶段会按天统计话题热度、智能体共现频率等。“协同检测”则是一个更复杂的模式识别过程，它从三个维度寻找可疑的协同行为：
  1. 时间聚类：超过3个智能体在2小时内密集讨论同一话题。
  2. 内容相似性：使用Jaccard距离计算不同智能体发布内容的主题向量相似度，过高则可能是有组织的宣传。
  3. 结构聚类（回复小圈子）：分析回复网络，如果发现一个小群体内部互动比例超过80%，而与外部互动很少，这可能是一个封闭的协作团体。
• 简报生成（Briefing）：最后，使用能力更强的Claude Sonnet模型，将前面所有阶段产生的洞察——高分智能体、热门话题、新发现的协同网络——整合成一份结构化的、带引用和数据的自然语言简报。这个过程每6小时自动执行一次。

状态管理与容错机制：这是管道稳定运行的“神经系统”。我们采用了基于游标（Cursor）的水位线设计。每个处理阶段完成后，都会在数据库里记录一个时间戳或最后处理ID作为“游标”。下次运行时，只会处理这个游标之后的新数据。这保证了整个管道的幂等性——无论因为网络问题或部署需要重新运行多少次，都不会产生重复数据或丢失数据。同时，我们使用Redis分布式锁（SET NX EX命令）来确保同一时间只有一个服务器函数实例在执行某个关键阶段，防止并发冲突。

3. 技术栈选型与实战心得

3.1 前端与全栈框架：Next.js 14 App Router

我们选择了Next.js 14并全面采用App Router模式。对于这样一个数据密集、兼具实时仪表盘和复杂后台任务的项目，Next.js提供了绝佳的全栈解决方案。

• 为什么是App Router？App Router的服务器组件（Server Components）让我们能在服务端直接查询数据库并渲染初始HTML，大大提升了仪表盘页面的加载速度。对于不常变的数据（如智能体档案），这几乎是即时的。而需要交互的部分（如图表、搜索），则用客户端组件处理。
• API路由的便利性：所有的数据处理管道阶段，都被实现为app/api/cron/下的API路由。Vercel可以很方便地将其设置为定时触发的Cron Job，管理起来比独立的服务器或复杂的任务队列要简单得多。
• 实操心得：
  • 在Server Component中直接使用async/await获取数据非常直观。但要注意，如果查询复杂，可能会阻塞页面渲染。我们的策略是，对核心数据用Server Component快速渲染，对附属数据或用户交互触发的数据，用React的useEffect或TanStack Query在客户端获取。
  • 使用react-wrap-balancer这样的库来处理仪表盘中标题文字的换行，能让UI看起来更专业。
  • 对于需要频繁更新的数据视图（如实时网络图），我们采用了Server-Sent Events (SSE)或WebSocket（通过单独的服务器函数实现）进行推送，但这部分超出了基础管道的范畴。

3.2 数据库与ORM：PostgreSQL (Neon) + Drizzle

数据存储是核心。我们选择了PostgreSQL，因为它对JSON数据的良好支持、强大的聚合查询能力以及事务可靠性。为了匹配无服务器架构，我们使用了Neon，这是一个真正的Serverless PostgreSQL服务，它按计算和存储用量计费，并且支持分支等强大功能。

• ORM选型：Drizzle：我们没有选择更流行的Prisma，而是用了Drizzle ORM。原因有三：1)类型安全极致：Drizzle的查询构建器能推导出极其精确的TypeScript类型。2)性能：Drizzle生成的SQL更接近手写，没有Prisma有时会产生的冗余查询。3)轻量级：对于复杂的数据聚合操作，我们有时需要直接写原生SQL，Drizzle对此的支持更友好（sql模板字面量）。
• 数据模型设计：我们设计了超过30张表，核心包括agents（智能体）、actions（行为记录）、topics（话题）、interactions（交互边）、pipeline_cursors（流水线游标）等。其中，interactions表存储了用于PageRank计算的图边数据，包含源智能体、目标智能体、交互类型、权重和质量分数。
• 踩坑记录：
  • 连接池管理：在Serverless环境中，每次函数调用都可能新建数据库连接。必须使用连接池（Neon自带，或通过pg库配置）并设置合理的超时和最大连接数，否则极易耗尽数据库连接。
  • 索引优化：对于actions（按时间、智能体ID查询）、interactions（按源/目标智能体查询）这类海量表，必须在相关字段上建立索引。我们使用了Drizzle的迁移工具来管理索引的创建和变更。

3.3 AI集成：Anthropic Claude API

LLM是系统的“智能核心”。我们根据任务特点选择了Anthropic的Claude模型家族。

• 任务分配：
  • Claude Haiku (enrichment)：用于行为数据的实时分类和打标。Haiku速度极快、成本最低，适合处理海量的、相对简单的文本分析任务。我们设计了一套清晰的提示词（Prompt），引导模型输出结构化的JSON，包含情感、原创性等分数。
  • Claude Sonnet (briefing)：用于生成最终的叙事性简报。Sonnet在理解复杂上下文、进行归纳总结和创造性写作方面更强。我们提供给Sonnet一个包含智能体分数、话题趋势、协同警报的结构化数据摘要，让它生成一份给人类管理者看的、带重点标记的简报。
• 成本与性能优化：
  • 批量处理：在enrich阶段，我们不会一条一条调用API，而是将30条行为数据打包成一个批次发送，显著减少了API调用开销和延迟。
  • 缓存：对于频繁出现的、相似的话题名称或智能体描述，我们会将LLM的解析结果缓存在Redis中一段时间，避免重复计算。
  • 提示词工程：这是保证输出质量稳定的关键。我们为每类任务都编写了详细的系统提示词（System Prompt），明确角色、输出格式和评分标准，并进行了大量的测试和迭代。例如，在判断“协同信号”时，我们会让模型寻找“呼吁行动”、“使用相同标签”、“重复特定口号”等具体模式，而不是一个模糊的感觉。

3.4 任务调度与分布式锁：QStash + Upstash Redis

如何可靠地驱动这个每6小时运行一次的复杂管道？我们选择了QStash作为任务调度器，Upstash Redis实现分布式锁。

• QStash：它是Upstash提供的无服务器消息队列和调度服务。你可以通过一个简单的HTTP调用或Cron表达式来触发一个API端点（即我们的管道阶段）。它的优势是完全无服务器、高可靠，并且内置重试机制。我们将每个管道阶段都暴露为一个API端点，然后用QStash设置定时任务链：先触发ingest，成功后再触发enrich，依此类推。
• 分布式锁的实现：这是防止管道阶段并发执行导致数据混乱的关键。我们使用Redis的SET key value NX EX seconds命令实现了一个简单的锁。

  // 伪代码示例：获取锁 const lockKey = `pipeline:lock:${stageName}`; const lockValue = `${Date.now()}:${randomId}`; // 唯一标识 const acquired = await redis.set(lockKey, lockValue, 'NX', 'EX', 30); // 锁30秒 if (acquired) { try { // 执行阶段任务... } finally { // 释放锁：只有锁的持有者才能删除，防止误删 const currentVal = await redis.get(lockKey); if (currentVal === lockValue) { await redis.del(lockKey); } } } else { console.log(`Stage ${stageName} is already running, skipping.`); }

• 实操心得：
  • 锁的粒度：我们为每个独立的管道阶段（ingest,enrich,analyze等）设置了不同的锁。这样，ingest和enrich理论上可以并行（如果设计允许），但同一个enrich不能同时运行两个实例。
  • 锁的超时时间（TTL）：必须设置一个合理的、略大于阶段平均执行时间的超时时间。太短可能导致任务未完成锁就释放，引发并发；太长则可能导致阶段失败后锁迟迟不释放，阻塞后续执行。我们根据Vercel函数的300秒超时限制，通常设置为200-250秒，并为每个阶段增加了“看门狗”机制，在任务完成时主动续期锁。

4. 核心算法与数据处理实战

4.1 基于质量权重的PageRank影响力计算

传统的PageRank算法假设所有出链（链接）是平等的。但在AI智能体的交互中，一个高质量内容产生的引用，其权重应该远高于一个简单回复。因此，我们实现了带质量权重的PageRank。

计算过程简述：

1. 构建图：节点是智能体，边是智能体A对智能体B的交互（如回复、提及）。每条边有一个初始权重W_initial（例如，回复=1，提及=2）。
2. 应用质量乘数：从enrich阶段获取该交互所在原内容的“质量分”Q（一个0到1的值，综合了原创性、情感积极性等）。边的最终权重W_final = W_initial * (0.7 + 0.3 * Q)。这里0.7是基础权重，保证即使质量分低也有一定影响；0.3是质量调整幅度。
3. 运行迭代计算：我们使用标准的幂迭代法计算PageRank。每个节点的分数会在其出链节点间，按边的权重比例进行分配。公式简化如下：PR(A) = (1-d) + d * Σ (PR(Tn) * W(Tn->A) / ΣW(Tn->Out))其中，d是阻尼系数（通常0.85），Tn是所有链接到A的节点，W(Tn->A)是边权重，ΣW(Tn->Out)是Tn所有出链权重之和。
4. 归一化：计算出的原始PageRank值范围不确定。我们将其除以当前网络中所有节点中的最大值，将所有分数归一化到[0, 1]区间，便于理解和比较。

注意事项：

• 这个计算是周期性的（每天一次），因为构建全图的计算量较大。我们将其放在analyze阶段，作为批处理任务。
• 对于新加入的智能体，其初始PageRank分数会有一个“冷启动”过程，通常需要几个周期才能稳定。在UI中，我们会给新智能体打上“新晋”标签，并说明其分数可能尚未充分反映影响力。

4.2 语义话题去重与合并引擎

AI智能体讨论的话题名称千奇百怪，“AI Governance”、“Governance of AI”、“人工智能治理”可能指的是同一件事。简单的字符串匹配会失效。我们构建了一个多层次的语义去重引擎。

处理流程：

1. 标准化：将所有话题名称转为小写，去除标点，进行词干化（stemming）或词形还原（lemmatization）。
2. 关键令牌提取：移除“the”，“and”，“for”等停用词，剩下的单词作为关键令牌。例如，“The Future of AI in Healthcare” -> [“future”, “ai”, “healthcare”]。
3. 生成哈希签名：对令牌集合进行排序（保证顺序无关），然后生成一个哈希值（如MD5）。拥有相同令牌集合的话题会得到相同的哈希，初步归为一组。
4. LLM辅助合并决策：对于哈希相同或高度相似（通过Jaccard相似度判断）的话题候选组，我们将它们打包，发送给Claude Haiku模型。提示词是：“以下是可能指代同一概念的话题列表，请判断它们是否应合并，并推荐一个最合适的合并后名称，同时给出合并置信度（0-1）。”
   • 输入：[“AI Safety Research”, “Research on AI Safety”, “Safety in AI studies”]
   • 期望输出：{“shouldMerge”: true, “canonicalName”: “AI Safety Research”, “confidence”: 0.95}
5. 执行合并：对于高置信度（如>0.8）的合并建议，系统会自动在数据库中将所有相关action记录的话题ID更新为规范话题的ID。低置信度的建议会进入一个审核队列，供人工最终确认。

这个设计的精妙之处在于：它结合了高效的算法（哈希）和模糊的智能判断（LLM），既保证了处理海量话题时的性能，又具备了理解语义细微差别的能力。

4.3 三层协同行为检测模型

检测AI智能体间的可疑协同，是平台的核心价值之一。我们建立了三道检测防线：

第一层：时间聚类分析

• 方法：扫描特定时间窗口（如24小时）内，所有围绕同一话题（经过上述去重后）的行为。如果发现超过N个（如3个）不同的智能体，在非常短的时间间隔（如2小时）内集中发布了相关内容，则触发一个“时间协同”警报。
• 原理：自然、有机的讨论通常有时间上的分散性。高度同步的行为可能暗示有组织的发布计划。
• 实现细节：我们使用滑动窗口算法，按话题分组行为，计算每组行为时间的标准差。标准差极小且参与智能体数超过阈值，则标记。

第二层：内容相似性分析

• 方法：对于同一时间段内、不同智能体发布的内容，我们提取其关键词向量（TF-IDF或简单的词袋模型），然后计算两两之间的Jaccard相似系数。J(A,B) = |A ∩ B| / |A ∪ B|如果一组智能体（>=3）两两之间的平均Jaccard相似度超过一个阈值（如0.6），则触发“内容协同”警报。
• 原理：即使讨论不同子话题，如果用词、句式结构高度雷同，也可能存在模板化或协同创作的痕迹。
• 优化：为了提高性能，我们只对在时间聚类中已被标记的智能体组进行全量的内容相似性计算。

第三层：结构聚类（回复小圈子）分析

• 方法：在特定话题的讨论线程中，构建一个以智能体为节点的回复关系有向图。使用社区发现算法（如Louvain算法）或简单的聚类分析，寻找内部连接紧密、外部连接稀疏的子图。
• 指标：计算潜在小圈子的内部互动比例。内部边数 / (内部边数 + 指向外部的边数)。如果这个比例超过一个很高的阈值（如80%），并且圈子成员数大于2，则触发“结构协同”警报。
• 原理：一个健康的讨论社区应该有广泛的交叉对话。如果一个小组只内部互相回复、点赞，几乎不与其他参与者交流，这可能是一个封闭的、有特定议程的团体。

警报聚合：一个协同事件可能同时触发多层警报。最终在前端，我们会展示一个综合的“协同风险评分”，并详细列出触发了哪几层检测规则，以及相关的证据链（时间线、相似内容片段、回复网络图）。

5. 部署、监控与运维实战

5.1 Vercel无服务器部署配置

将这样一个包含前端、API和定时后台任务的Next.js应用部署到Vercel，需要一些特定的配置。

vercel.json配置要点：

{ “functions”: { “app/api/cron/*”: { “memory”: 3008, // 为消耗资源的分析任务分配更多内存 “maxDuration”: 300 // Vercel最大超时时间（秒） }, “app/api/v1/*”: { “memory”: 1024, “maxDuration”: 30 // API响应应该更快 } }, “crons”: [ { “path”: “/api/cron/orchestrate”, // 总调度入口 “schedule”: “0 */6 * * *” // 每6小时运行一次，UTC时间 } ] }

环境变量管理：所有敏感信息（API密钥、数据库连接字符串）都必须通过Vercel项目的环境变量界面设置。在本地开发时，我们使用.env.local文件。切记不要将任何密钥提交到版本控制系统。

实操踩坑：

• 冷启动延迟：Serverless函数在闲置一段时间后首次调用会有“冷启动”延迟（几百毫秒到几秒）。对于定时任务这不是问题，但对于用户请求的API，我们通过设置Vercel的“Serverless Function Prewarming”功能（如果有）或保持一定的最低并发实例来缓解。
• 输出大小限制：Vercel函数响应体有大小限制（约4.5MB）。在analyze阶段生成大型图数据JSON时，我们曾触发此限制。解决方案是进行分页输出，或只传输计算后的摘要数据，原始数据让前端按需查询。

5.2 管道可观测性与错误处理

一个自动化管道最怕的就是在后台默默失败。我们建立了多层监控。

1. 结构化日志：每个管道阶段都使用像pino或winston这样的日志库，以JSON格式输出结构化日志，包含stage、runId、status、processedCount、error等字段。这些日志被自动发送到Vercel的日志流，并可以转发到像Logtail或Datadog这样的外部监控服务。
2. 数据库状态表：核心的pipeline_runs表记录了每次管道执行的元数据：开始时间、结束时间、状态（成功、失败、进行中）、每个阶段的输入/输出计数、错误信息（如果有）。仪表盘上有一个“系统健康”页面，直接展示这张表的最新记录。
3. 错误警报：我们集成了Cronitor或Updown.io这样的外部监控服务。每个关键阶段（orchestrate,briefing）的API端点都被添加为一个监控器。如果端点返回非2xx状态码，或者执行时间异常长，监控服务会立即通过邮件、Slack或短信告警。
4. 优雅降级与重试：
   • 如果某个数据源API暂时不可用，ingest阶段会记录错误，但跳过该源继续处理其他源，而不是让整个管道失败。
   • 对于LLM API调用失败（网络超时、速率限制），我们实现了指数退避重试机制。
   • QStash本身也支持失败重试，我们可以配置重试次数和间隔。

5.3 性能优化与成本控制

在无服务器架构下，性能和成本紧密相关。

性能优化策略：

• 数据库查询优化：这是最大的瓶颈。我们为所有常用的查询字段（如agent_id,created_at,topic_id）建立了索引。对于复杂的聚合查询（如计算过去7天的互动图），我们考虑使用物化视图（Materialized View）定期刷新，或者将计算结果缓存在Redis中。
• 计算任务分片：analyze阶段的PageRank计算如果针对整个网络进行，可能超时。我们的策略是：只对过去7天内有活动的“活跃子图”进行计算，大大减少了节点和边的数量。
• 流式处理与批处理结合：对于enrich阶段，我们使用LLM的批处理API，一次发送30-50条文本，而不是逐条调用，减少了网络往返开销。

成本控制措施：

1. LLM API成本：这是主要成本。我们严格选择模型：快而便宜的Haiku用于大量分类任务，强而较贵的Sonnet仅用于最终的简报生成。同时，通过缓存（Redis）和去重，避免对相同或极度相似的内容重复调用。
2. 数据库操作成本：Neon按计算单元（CU）计费。我们优化查询，避免SELECT *，使用分页（LIMIT/OFFSET或游标分页），并设置合理的连接池大小，防止空闲连接浪费。
3. 函数执行成本：Vercel Pro计划有足够的免费额度覆盖中小规模使用。我们监控函数的执行时间和内存使用，确保没有意外的内存泄漏或无限循环导致费用激增。
4. 监控成本本身：我们甚至用Clawstrate监控自己的管道执行成本和性能，形成了一个有趣的“自指”循环。

构建Clawstrate的过程，是一个将前沿的AI能力、分布式系统思想和务实的前后端工程紧密结合的旅程。它不仅仅是一个监控工具，更是一种理解未来人机混合、智能体驱动的复杂社会经济系统的尝试。每一个技术选型和架构决策背后，都是对可靠性、可扩展性和成本的反复权衡。希望这份详尽的拆解，能为那些同样在探索AI智能体生态、或正在构建复杂数据管道的开发者们，提供一些切实可行的参考和启发。