文章 | Badbottle's blog

这里记录我在公司 AI 后端实习期间，对微服务架构、Agent 工程化、可观测性、浏览器自动化和协作方法的系统总结。文中对公司产品、内部模块和业务细节均做了泛化处理。

ℬ𝒶𝒹𝒷0𝓉𝓉𝓁ℯ2026/9/4小于 1 分钟

背景

某公司 AI 后端平台是一个处理社交信息的 Python AI 微服务系统。它需要把一条输入拆成多个可独立演进的步骤：内容解析、候选识别、风险过滤、Agent 分析，再把结果回传给上层应用。单体函数很难同时满足异步处理、可扩展、可追踪和故障隔离，因此系统采用 Monorepo 管理多个 FastAPI API 与 Worker，并用 DAG 和消息队列连接各个节点。

技术栈

层次	技术与职责
API	FastAPI，提供任务、配置和调试接口
编排	DAG 状态机，保存节点依赖与上下文
消息	Kafka 为默认通道，同时兼容 RabbitMQ
Worker	独立消费节点消息，执行 Handler 并发送回调
数据	PostgreSQL、SQLAlchemy 2.x 异步会话、Pydantic 模型
缓存与状态	Redis，用于幂等租约、任务状态和短期上下文
AI 能力	Agno Agent、工具调用、结构化输出、模型降级
观测	Langfuse Trace、Prometheus 指标、阿里云 ARMS 告警、结构化日志

ℬ𝒶𝒹𝒷0𝓉𝓉𝓁ℯ2026/9/4大约 3 分钟

DAG 与消息队列驱动的 AI 微服务

为什么需要 DAG

情报分析通常不是一次模型调用，而是多步处理：解析原文、识别显式和隐含标的、查询市场数据、过滤风险候选、执行最终优化。步骤之间存在依赖，但并非每条情报都经过同一条路径。DAG 将流程拆成节点并保存依赖关系，节点只通过上下文和消息通信，从而实现解耦、并行和故障隔离。

原始情报
  ├─▶ 显式提取 ─┐
  ├─▶ 账号找币 ──┼─▶ 结果合并 ─▶ 最终优化
  └─▶ 图片分析 ─┘

ℬ𝒶𝒹𝒷0𝓉𝓉𝓁ℯ2026/9/4大约 3 分钟

Agent 与 Skill 工程化实践

从 Chatbot 到 Agent

判断一个系统是不是 Agent，可以问一句：下一步由谁决定？

形态	决策者	流程	适用场景
Chatbot	无	一问一答	翻译、简单问答
Workflow	开发者	代码预定义	路径稳定、强可审计
Agent	模型	运行时动态选择	意图开放、多工具组合

ℬ𝒶𝒹𝒷0𝓉𝓉𝓁ℯ2026/9/4大约 3 分钟

Agent 工具调用与结构化输出

为什么不能只拿一段文本

模型输出一段自然语言时，人可以理解，程序却很难稳定判断它是否包含候选对象、分类信息和后续动作。平台使用 Pydantic 定义结构化结果模型，把 Agent 输出变成后端可以继续处理的契约。

工具调用的完整链路

系统 Prompt + 工具 schema
          │
          ▼
      模型选择工具
          │
          ▼
  ToolCallController 校验
          │
          ├─ 通过：执行工具并记录结果
          └─ 拒绝：返回可解释的错误
          │
          ▼
   工具结果回到对话上下文
          │
          ▼
       模型继续推理
          │
          ▼
    Pydantic 校验最终输出

ℬ𝒶𝒹𝒷0𝓉𝓉𝓁ℯ2026/9/4大约 3 分钟

Langfuse、Prometheus 与 ARMS 可观测性

三种观测视角

AI 微服务的问题通常横跨模型、消息和基础设施，单看日志很难还原完整过程。该平台将观测拆成三个互补层次：

层次	工具	回答的问题
Trace	Langfuse、OpenTelemetry	一次任务经过了哪些节点？模型看到了什么？
指标	Prometheus	系统是否变慢、积压或错误率升高？
日志与告警	结构化日志、阿里云 ARMS	何时发生、影响范围多大、是否需要通知？

ℬ𝒶𝒹𝒷0𝓉𝓉𝓁ℯ2026/9/4大约 3 分钟

Trace 驱动的复杂问题排查

先描述现象，再讨论根因

AI 系统的“结果不对”可能来自多个阶段。排障第一步不是修改 Prompt，而是把用户看到的现象写成可验证的问题：

是没有候选，还是候选被过滤？
是页面没有展示，还是后端没有生成？
是新任务复现，还是页面读取了历史 Trace？
是一个节点错误，还是多个节点合并时发生了丢失？

我的五步方法

1. 锁定任务和时间窗口

通过任务 ID、消息 ID、页面链接和发生时间找到唯一执行。先确认页面读取的是新 Trace 还是历史 Trace，避免把部署后的代码与旧数据混在一起。

ℬ𝒶𝒹𝒷0𝓉𝓉𝓁ℯ2026/9/4大约 3 分钟

语音智能体与实时数字人技术调研

调研背景

语音智能体和实时数字人看起来都是“输入语音、输出会说话的人”，但真正决定能否落地的是端到端延迟、数字人驱动方式、接口开放程度、并发限制和部署成本。为了给后续技术接入提供依据，我围绕 Higgs Avatar、Boson Avatar，并参考 Heygen、D-ID 等产品做了能力调研、本地测试和接口限制验证，最终输出专项调研文档。

统一评估维度

维度	需要验证的问题
输入	支持文本、语音还是实时音频流？是否需要固定格式？
输出	返回视频、音频还是 WebRTC/WS 流？能否逐字或分片返回？
实时性	首帧延迟、端到端延迟、连续对话是否稳定？
驱动能力	静态头像、口型同步、表情动作和自定义数字人支持到什么程度？
接口	鉴权、回调、并发、时长、文件大小和限流如何？
落地	是否支持本地测试、私有化或稳定的生产 SLA？

ℬ𝒶𝒹𝒷0𝓉𝓉𝓁ℯ2026/9/4大约 3 分钟

Ego Browser 与 AI 辅助验证

为什么需要浏览器验证

只读后端代码和接口文档，无法确认用户最终看到的页面是否真的符合预期。公司内部分析页面的问题常常涉及历史 Trace 和前端字段映射，因此我使用 Ego Browser 进行登录态下的页面观察和流程验证，把“接口返回了什么”和“页面展示了什么”放在同一条证据链中。

一次验证的基本流程

选择隔离浏览器任务空间
          │
          ▼
确认页面、任务 ID 和时间窗口
          │
          ▼
观察 DOM / 页面文本 / 截图
          │
          ▼
执行点击、输入和筛选操作
          │
          ▼
对比页面结果与 Trace、接口 payload
          │
          ▼
记录复现步骤和验证结论

ℬ𝒶𝒹𝒷0𝓉𝓉𝓁ℯ2026/9/4大约 2 分钟

Superpowers 驱动的 AI 开发工作流

从“直接改”到“先建立证据”

刚开始使用 AI 编程工具时，最容易陷入“看到问题就让模型改代码”。在公司 AI 后端项目中，需求往往跨越 Prompt、DAG、消息队列、数据库和前端展示，直接修改很容易误伤已有行为。我逐步形成了以 Superpowers 为核心的工作流：先澄清目标，再拆解问题，最后用测试和证据收敛结果。

关键环节

Brainstorming：先确认问题边界

先区分是简单修复、可行性验证还是架构调整；明确用户现象、成功标准、影响范围和不能改变的行为。对于 Type、过滤和最终展示这类敏感逻辑，先列出当前行为与目标行为，再决定是否需要改动。

ℬ𝒶𝒹𝒷0𝓉𝓉𝓁ℯ2026/9/4大约 2 分钟