上一篇文章研究 Google 的 A2UI——一种声明式 Agent UI 协议，让远程不可信 Agent 把富交互界面安全地送回客户端。那张端到端时序图里有一个被一笔带过的角色：传输层。A2UI 反复强调「传输可插拔（A2A / AG-UI / SSE / WebSocket）」，它不绑定传输。
这就留下一个更底层的问题：UI 消息（一行行 JSONL）到底是怎么从远程 Agent 流到你客户端的？如果 Agent 在别的公司、别的云、用别的框架，它们之间靠什么对话？
答案之一，就是这篇的主角——A2A（Agent2Agent）协议。它是 A2UI 最重量级的传输底座，但它的意义远不止「传 UI」：这是 Google 主导、Linux Foundation 治理、150+ 组织支持的 Agent 间通信通用语言。
本篇就从 A2UI 的传输层向下深挖，讲透 A2A：为什么需要它、核心机制、与 MCP 的分工，以及它如何承载 A2UI 的流式 UI。
设想你在和一个 Agent 聊天，让它帮你订一桌餐。它没有跟你来回文字拉扯（几人？哪天？几点？），而是直接甩给你一个带日期选择器、时间段、确认按钮的表单——你点几下就搞定。
关键来了：这个表单，不是你本地 App 预先做好的页面，而是那个跑在别的公司服务器上的远程 Agent，「画」出来递给你的。
这立刻引出两个尖锐的问题：
传统答案是把 HTML/JS 塞进 iframe——又重、又割裂、又是安全噩梦。Google 给出了另一个答案：A2UI（Agent-to-User Interface），一套声明式 UI 协议。它的设计纲领一句话能说完：
传输一种 UI——像数据一样安全，又像代码一样有表现力。
这篇就讲透 A2UI：为什么需要它、它的三个反直觉设计、安全模型，以及 UI 协议「三巨头」里它和 MCP Apps、ChatKit 到底差在哪。最后落到一个实践——如何把它的思想借到一个自研 Agent 框架（以我的 Hermes 为例）。
“Loop Agent”（循环型智能体）最近火得一塌糊涂。Addy Osmani（Google Chrome 工程负责人）连写三篇文章把它系统化，社区里 Ralph Loop、loop engineering、self-improving agent 这些词到处飞。
但绝大多数讨论都跑偏了——焦点全放在”让 AI 一直跑、跑很多轮”上。这是对 Loop 最大的误读。Loop 真正值钱的，从来不是”跑得久”。如果你只是开一个很长的对话让 AI 反复改，那不叫 Loop，那只是”更累的人工盯着”。
它的价值，在另一件事上。
顺带说一句：很多人拿 Loop 和”长会话”比来比去，争论它俩是不是一回事。那只是副产品，不重要。重要的是 Loop 凭什么值得被单独拎出来——这才是本文要讲清的。
Addy 给 Loop Engineering 下的定义，是我见过最准的一句：
Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.
（Loop 工程，就是把你这个”负责一轮轮提示 agent 的人”替换掉。你来设计那个替代你的系统。）
这句话点透了 Loop 的第一层价值：解放人。
传统做法里，每一轮要不要继续、做得对不对、什么时候算完——全是你在推动，AI 只是在你驱动下接力执行。Addy 把这比作”把 AI 当成只有短期记忆的实习生”：你给清单、你检查、你存盘。driver 是你，judge 也是你。
Loop 把这个”你”工程化地抽走了。不是让你更省力地推，而是根本不需要你推。
Claude Code 开箱即带两个联网工具：WebSearch 负责发现，WebFetch 负责提取。能力清单看似完整，但在真实的 Agent 联网任务中，会接连遇到三类典型障碍：
WebFetch 返回的是「环境异常」的空壳；curl 仅能取回骨架；WebFetch 耗时长，且回传的大段 HTML 会将上下文撑爆。这三类障碍暴露的不是 Claude Code 的能力不足，而是缺少两样东西：一套联网的调度策略，以及一层浏览器能力。原生工具是零件，却没有引擎将其组织起来。
web-access（当前 v2.4.1，作者一泽 Eze）补全的正是这一层：联网策略 + CDP 浏览器代理 + 站点经验积累（CDP 即 Chrome DevTools Protocol，Chrome 浏览器的底层控制协议）。它的特别之处在于，这并非一个「代为联网的脚本」，而是一份指导 Agent 如何思考联网任务的哲学文档，外加一个最小化的 CDP 代理实现（572 行零依赖 Node 脚本）。
本文不做功能罗列，而是从源码层面将其拆透：先阐述设计哲学，再解析 CDP Proxy 的工程实现，最后落到笔者主导的一个 AIGC 内容生产系统——以一个真实生产系统的技术选型与边界识别，印证 web-access 的价值。需要强调的是，本文的真正主角是笔者的工程实践（服务端 axios 爬虫框架、OPRO Prompt 自我进化，OPRO 即 Optimization by PROmpting，基于提示的 Prompt 自动优化算法），web-access 是用来反哺验证选型边界的业界参照。全文只回答一个问题：一个优秀的 Agent Skill，究竟该具备怎样的形态——以及一个工程师如何从自己的生产实践中识别技术边界、并找到解法。
Claude Code Insights 是一个系统化追踪 Claude Code 版本演进与 Anthropic 技术生态的知识库项目。
包含三大模块：版本编年史、文章知识库、HTML 示例集，全部零依赖，浏览器直接打开。
GitHub: FrizzleFur/claude-code-insights
作为 Claude Code 的深度用户，我追踪了它从 v0.2.21 到 v2.1.150 的完整演进历程。在这个过程中，我发现：
于是，我构建了三个互补的模块来解决这个问题
Flow-Deep 是 FlowKit 的全量深度引擎，所有质量关卡不可跳过，适用于复杂/重要/高风险任务。
本文是 FlowKit 系列教程第五篇（最终篇）。
GitHub: FrizzleFur/flowkit | 系列导航
Flow-Deep 定位为高风险任务的”保险模式”。与 /flow 相比，核心区别在于不可跳过：
Flow Skill 是 FlowKit 的轻量编排引擎，将多个技能串联为”优化 → 思考 → 规划 → 执行”管道，通过参数灵活控制每个阶段。
本文是 FlowKit 系列教程第四篇。
GitHub: FrizzleFur/flowkit | 系列导航
Multi-Agent Skill 是 FlowKit 的 Agent Teams 方案生成与执行引擎，通过 tmux 分屏实现多 Agent 真正的并行执行。
本文是 FlowKit 系列教程第三篇。
GitHub: FrizzleFur/flowkit | 系列导航
单 Agent 模式下，所有任务串行执行。但实际开发中，很多任务是可以并行的：
1 | 串行: 认证模块(2h) → 数据库迁移(1h) → API 测试(1h) = 4h |
更重要的是，不同任务需要不同的专业角色。一个 Agent 同时做后端开发、测试和安全审计，不如三个专业 Agent 各司其职。
Prompt Skill 是 FlowKit 的基础模块，基于乔哈里视窗理论和 3S 原则，提供 Prompt 自动评分、问题诊断和优化。
本文是 FlowKit 系列教程第二篇。
GitHub: FrizzleFur/flowkit | 系列导航
大多数人写 Prompt 只关注”怎么措辞”，但 Prompt 的质量问题远比措辞复杂。核心难点在于：你知道的东西，AI 不一定知道。
这就是为什么需要一个系统化的评分框架 —— 不只看文字质量，而是从认知科学角度评估 Prompt 的信息完整度。
FlowKit 是一套为 AI 编程助手设计的结构化任务编排工具集。本文是系列教程的第一篇，从设计动机出发，讲清楚”为什么要造这个轮子”以及整体架构。
GitHub: FrizzleFur/flowkit