WebRTC 与实时应用开发的智能体工作流

作者：Justin Williams
原文：https://webrtc.ventures/2026/07/webrtc-agentic-workflows-real-time-development/

智能体工作流是通常所称“氛围式编码”的一种规范化形式：向编码智能体分配任务并提供所需上下文，然后让它在你的代码库中进行规划、编辑和测试，而你只需审查结果。如果操作得当，生产力的提升将非常显著。Philipp Hancke 在其关于“氛围式编码”的 WebRTC 博文中描述了将更改合并到 libWebRTC、Firefox 甚至 Pion 中的经历，这些工作过去往往需要等到找到一个空闲周才能深入研究陌生的代码。但这之所以能行得通，是因为这些代码库拥有严密的防护措施：测试、一致的工具链，以及会拒绝任何马虎代码的审阅者。智能体行动迅速；而围绕它的工程实践，正是确保这种速度安全的关键。

当我们在 WebRTC.ventures 将 AI 整合到 QA 团队时，也获得了同样的启示。本文将运用这些理解，并借鉴我们在 WebRTC.ventures 开发实际系统过程中积累的经验。我将详细介绍我在构建实时应用程序时使用的工作流程：作为项目核心的上下文文件、将会话上下文转化为测试和审查的自定义技能，以及在日常使用中养成的习惯。

为 WebRTC 项目编写 AGENTS.md 文件

一个清晰、结构完整的顶层 AGENTS.md 或 CLAUDE.md 文件是代理的初始上下文，因此它是规划项目的理想位置：包括应用程序类型、技术栈、设置方式以及它所依赖的任何其他服务。LLM（低级领导力经理）已经掌握了 WebRTC 的基础知识，因此无需再进行讲解。过度解释只会使上下文文件臃肿，并导致你试图避免的那种自信却混乱的输出。一个好的上下文文件通常只需要告诉代理你正在构建什么以及你使用什么工具来构建它即可。除此之外，我们避免重复项目中其他地方已有的内容，而是提供指向相关文档或代码的链接。

以下是一个多方广播平台的具体实现示例：

# Agent Instructions: RealTime Studio

## What we're building

A multi-party live broadcast platform: presenters join a real-time WebRTC
call, a server-side layout engine composites their feeds into a single
program stream, and that stream is recorded and distributed to viewers.

## Stack

- **Front end**: TypeScript, React/Next.js presenter and producer consoles.
- **API**: Node/TypeScript GraphQL server; issues call tokens, owns session
  and participant state.
- **Signaling**: WebSocket service with a Redis-backed fan-out for
  real-time presence and control events.
- **Media**: a managed LiveKit WebRTC SFU carries the live call; a
  headless-browser layout engine (Xvfb + FFmpeg) renders the composited
  program feed.
- **Infra**: AWS behind Terraform: EKS for services, CloudFront for
  delivery, CloudWatch for logs.
- **E2E**: Playwright tests covering the front end across the stack.

## Repos

- `api`: GraphQL API, session/token logic, deploy manifests.
- `signaling`: WebSocket presence and control fan-out.
- `media-server`: headless compositor (browser + FFmpeg + media server).
- `web`: presenter/producer front end.
- `infra`: Terraform for AWS, EKS, and delivery.
- `e2e`: Playwright E2E test repo, includes context and instructions.

## Where truth lives

- Code, Terraform, and Kubernetes manifests are the source of truth.
- Treat `plans/` as proposals and most of `docs/` as supporting context,
  not a contract, unless a doc is explicitly the maintained integration
  agreement.
- When docs and code disagree, follow the code and flag the mismatch.
- Don't copy operational facts into new docs; link the source file instead.

## Conventions

- One branch per ticket; use isolated worktrees for parallel cross-repo
  work.
- Region, namespaces, and service config live in Terraform and
  `api/config/`, read them there rather than hard-coding values.

## Guardrails

- Never commit secrets, tokens, or credentials. Read them from the existing
  config sources, never inline them.
- The call path is latency-sensitive. Flag anything that adds blocking work
  to signaling or media handling rather than shipping it quietly.
- Verify connectivity across network types, not just on a local network.
  Confirm the TURN and relay paths keep working for the call scenarios this
  app supports.
- Don't touch infra (Terraform, EKS, CloudFront) without explicit sign-off.
  Propose the change in `plans/` first.
- Stop and ask before changes that span repos or touch session/token logic.
  Do not guess at the contract.
- A task is not done on a green compile. Run the relevant tests first (see
  below) and report anything you could not cover.

## Further context

Detailed guides live in `docs/agent/`. Read the relevant one before you
start, so this file can stay short:

- `docs/agent/writing-features.md`: how we structure and ship a feature
  across the repos.
- `docs/agent/running-tests.md`: running unit, integration, and Playwright
  E2E suites locally and in CI.
- `docs/agent/signaling.md`: the WebSocket protocol and message shapes.
- `docs/agent/review.md`: the review checklist and conventions we expect.

关键不在于这个具体的文件，而在于它背后的模式。告诉智能体你在构建什么，以及你使用什么来构建它，设置几个对你的系统真正重要的安全规则，并提供指向详细信息的链接，而不是将其内联。这些安全规则体现了项目的具体内容。例如，一个实时媒体应用需要确保通话路径畅通，并在各种网络环境下保持可靠性。每个项目都有不同的优先级，而这些项目限制正是模型无法自行推断的部分。

为端到端测试和代码审查定制 Claude 代码技能

为项目定制技能，正是智能体开发真正开始发挥作用的地方。模型本身已经掌握了大量信息；只需添加正确的上下文和指令、MCP 服务器以及对项目内部机制的了解，即可获得稳定且可重复的工作流程。

以功能开发或 bug 修复为例。你可以进行一次经典的提示会话，也可以尝试“循环工程”（loop engineering）——这是一种较新的方法，有人对其推崇备至，也有人仍持怀疑态度。（这与代理框架运行的内部循环不同。）该领域发展迅速，因此保持灵活性比站队更重要。无论采用哪种方式，我发现有一项技能非常有用，那就是直接从会话上下文中生成 Playwright 端到端测试。

到会话结束时，智能体已经构建了扎实的上下文：包括应用程序的整体情况，以及对其刚刚完成的工作的深入了解。这可能包括来自 API 服务器的相关 API，或者如果你让智能体通过 Playwright MCP 启动浏览器来精确测试哪些内容发生了变化，还包括它执行的手动步骤。这是保持上下文有效并将其转化为测试的最佳时机，同时也能捕获那些如果尚未写入代码就会丢失的任何文档信息。

这项技能本身很简单。它指向端到端代码库，要求代理捕获刚刚完成的工作，遵循现有规范，并为新功能或修复编写有用且不重复的测试。这样可以避免日后补写测试、跳过手动 QA 注释，以及因发布未经测试的内容而导致的回归问题。它同样适用于单元测试和集成测试。

妙处在于它的灵活性。你可以在提示中提及这项技能，然后将其引向略有不同的方向，例如：

Use the fundamentals and knowledge from the /gen-e2e-test skill to write
any integration tests that may be missing for this feature, and write up
some notes for QA with their testing steps.

这种技能可以体现在以下几个方面：

---
name: gen-e2e-test
description: Generate Playwright E2E tests from the current session context.
  Use right after implementing a feature or bug fix, while the agent still has
  context on what changed, which APIs were touched, and how it was manually
  verified.
---

# Generate E2E Test

Turn the work just completed in this session into Playwright end-to-end
tests.

## Steps

1. Review what changed this session: the feature or fix, the APIs or
   signaling messages involved, and any manual steps used to verify it
   (including anything run through the Playwright MCP browser).
2. Read the existing tests in the E2E repo and match their conventions:
   structure, fixtures, naming, and helpers. Reuse shared setup instead of
   repeating it.
3. Cover only the new behaviour. Do not duplicate cases already handled
   elsewhere.
4. Prefer existing page objects and helpers over inline selectors.
5. Run the new tests and confirm they pass before finishing. Note anything
   you could not cover and why.

## Notes

- Keep each test focused on a single behaviour.
- If the work relied on something not obvious from the code, like a timing
  assumption or a tricky negotiation step, leave a short comment so the next
  person sees it.

代码审查技能

另一个值得定制的技能是代码审查。Claude Code已经内置了一个`/code-review`技能，它运行良好，涵盖了安全检查等内容，但如果将其与你的项目上下文相结合，效果会更好。你可以创建一个自定义技能，引用内置技能，并添加项目上下文、指南和测试说明，从而更好地指导代码审查。

我运行两种变体。一种用于提交或推送代码前的自我审查，另一种用于对其他开发人员的代码进行同行评审。

同行评审变体与顶级上下文文件配对，因此只需类似/peer-review the branch <branch_name> for repo <repo_name>这样的提示即可，该技能直接使用 Git，无需像 gh 这样的额外依赖项。我将同行评审意见以 Markdown 文件的形式保存在指定目录中，以便我可以编辑它们并保留我想要的内容，然后手动应用这些评审意见，并直接在 GitHub 上的 PR 中发表评论。
对于自我评估，我会设置成当它发现问题时提示我应该采取什么行动。这两项功能设置起来都很简单，因为它们基本上都是对 Claude 技能的封装，而且当你整天需要频繁切换工作内容时，它们真的很有帮助。

使用 Playwright MCP 测试 WebRTC 条件

智能体开发远不止编写和审查代码。正如我之前提到的，它的价值很大程度上在于让智能体将会话上下文转化为测试用例，以及可以传递给其他团队的信息。记录已完成的工作，进行清理，并使其易于后续人员阅读，这无疑会显著提高工作效率。如果其他团队保留了他们自己接收此类信息的上下文或技能，效果会更好。这样，每次都可以使用相同的格式，而无需自己记住所有细节，两个团队还可以就共享的上下文和技能进行协作，从而实现更顺畅的交接。

让代理通过 Playwright MCP 进行测试也很棒。我最近在开发一个连接性指示器，并让代理模拟糟糕的网络和 CPU 使用情况。它通过封装 `getStats()` 方法并注入不良统计数据来模拟连接降级。我让代理截取屏幕截图，以便在实时观察其运行情况后使用。我把截图发送给了 QA 和产品团队，让他们了解预期结果，并就设计和用户体验提出意见。

我也喜欢让智能体在我展示自己开发的项目时生成幻灯片所需的 SVG 图片。有了代码和上下文信息作为提示，生成的图片清晰度出乎意料地高。