现代 Agent 工程扩展:协作、协议与 Computer Use

这篇补齐现有路线在应用层的四个缺口:多智能体协作、A2A/ACP 协议、Browser/Computer Use、长运行个人 Agent。
先把标题里的黑话过一遍:A2A(Agent2Agent,Agent 之间互相发现、派任务用的协议)、ACP(Agent Client Protocol,Agent 接入编辑器、终端这类宿主程序用的协议)、Computer Use(让模型看屏幕截图、操作鼠标键盘去直接用软件)。
这一篇定位是扩展线,不做入门主线:建议先完成 00-Java & Agent学习路线、通过 23-Agent Harness工程-从最小循环到生产运行时 建立运行时地图,并跑通 Tool/RAG(检索增强生成)/MCP/Trace,再回来读。

参考基线:datawhalechina/Agent-Learning-Hub,本地对照版本为 commit d7967513ace303618ac2e37732468f6e127e4de1(2026-06-05)。
本篇只吸收其路线判断,再按本笔记库的 Java 后端与工程验收方式重组。

先做结论:扩展能力不是新的主循环

现代 Agent 系统仍然建立在已有内核上:

Model + Context + Tool + Loop + Stop Policy + Trace

扩展线做的是把这个内核放进更大的系统边界:

这张表每行是一层扩展:第二列是这层要解决的新问题,第三列是学的时候要盯住的核心对象。

几个第一次出现的词先解释一下:Smoke Test 是冒烟测试,跑一遍最基本流程确认没坏,类似你写完接口先 curl 一下;
Capability 指一项被声明出来、可以被发现和授权的能力;
Artifact 指协作产出的产物文件(报告、代码、数据),单独存放并编号,而不是塞在聊天消息里;

Heartbeat 是心跳,定时确认服务还活着,和 Netty 里的心跳包是同一个意思。

关键判断:不要因为出现多个角色名,就把单 Agent 能解决的问题改成多 Agent。 扩展层必须证明它降低了失败率、上下文污染或人工成本,否则只是增加网络调用和调试难度。

Agent、Workflow、Multi-Agent 的选择

接到一个需求,先按这张表从上往下对号入座:越往下模型自主性越强,也越难调试、越贵。能用上面的形态解决,就不要往下升级。

升级到多智能体前的四个问题

1. 子任务是否能写成独立输入/输出契约?
2. 子任务是否值得拥有独立上下文预算?
3. 是否需要独立权限或不同工具集?
4. 是否能用 eval(评测:一组固定测试用例加统一评分口径,跑出成功率数字)证明它优于单 Agent 基线?

前三问里大多数答案是否,就先保留单 Agent;第四问如果连单 Agent 的基线数字都没测过,升级有没有效就无从证明。

Harness、Framework 与 Agent 本体

Agent-Learning-Hub 强调 harness engineering。harness 原意是马具,在 Agent 语境里指包在模型外面的那层工程设施:工具执行、权限判定、上下文管理、会话存储这些代码都算。
这与本笔记库的 Agent CLI 深水区是一致的。模型能力只是上限,harness 决定它能否稳定工作。

表里的 SLO 指服务等级目标(Service Level Objective),比如承诺 99.9% 可用、P99 延迟 2 秒以内,是产品层才需要背的指标。

读框架时不要只记 API。必须定位:agent loop 在哪里、状态由谁持有、工具如何注册、权限在哪里判定、context 如何压缩、trace 如何回放。

Skill、Tool、MCP、A2A、ACP 的边界

这五个概念解决的是不同层的问题。先把 MCP 展开说清楚:MCP(Model Context Protocol)是让 Agent 用统一方式接入外部工具和数据的协议,作用类似 JDBC 之于数据库:你实现一次 MCP server,所有支持 MCP 的客户端(Claude Code、Cursor 等)都能发现并调用它,不用为每个客户端单独写一遍集成。
A2A 和 ACP 在开头解释过。下面这张表里,第五列「不负责」最重要,混淆几乎都发生在把一个东西用到它不负责的场景。

「典型产物」列说的是你真正动手做这个东西时会写出什么。Tool 的 schema + executor:schema 是一份给模型看的参数说明(JSON 格式,写清这个工具叫什么、收哪些参数、每个参数什么类型),executor 是真正干活的那段执行代码,类比 Spring 里接口文档加 Controller 方法体。
Skill 的产物就是一个 SKILL.md 文件(写清什么时候用、步骤是什么)加配套脚本和模板。
MCP 的 tools/resources/prompts 是一个 MCP server 对外暴露的三类清单:可调用的工具、可读取的数据(文件、数据库查询这类)、可复用的提示词模板。
A2A 的 task、message、artifact 分别是任务单、过程消息和产物文件。
ACP 的 session、event、tool request 分别是一次会话、宿主里持续推送的增量事件(比如编辑器里逐字出现的回复)、以及 Agent 请求宿主替它执行工具的消息。

最短判定法

• 需要执行一个动作? → Tool
• 需要复用一套做事方法? → Skill
• 需要标准接入工具/数据? → MCP
• 需要把任务交给另一个 Agent? → A2A
• 需要把 Agent 嵌入 IDE/宿主? → ACP

Java 后端映射

Skill 那行的「渐进加载」单独说一下:Skill 不会一开始就整个塞进模型上下文。模型平时只看到每个 Skill 的名字和一句触发描述,判断当前任务命中了,才把 SKILL.md 正文和脚本读进来。
这样挂几十个 Skill 也几乎不占 token,思路和 MyBatis 关联对象的懒加载一样:先只留个引子,真用到才加载全文。

协议学习的验收标准:能画出一次请求的 envelope(信封字段,也就是包在业务数据外面的请求 ID、消息类型、时间戳这些元数据)、状态转换、超时、取消、错误和审计字段。只是「读完规范」不算数。

多智能体是协调系统

推荐拓扑

flowchart LR
    U[User] --> S[Supervisor]
    S --> R[Research]
    S --> W[Write]
    S --> V[Review]
    R --> A[Artifacts]
    W --> A
    V --> A
    A --> S

图里的关键角色是 Supervisor(协调者):它把用户目标拆成任务派给 Research、Write、Review 三个 worker,产物统一存进 Artifacts 再汇总回来。三个 worker 之间不直接聊天,所有交接都经过 Supervisor 和 Artifact 存储。

最小协作契约

给 worker 派活的消息长下面这样。重点是每个字段都可校验:干什么(objective)、能用什么(tools 和预算)、交回什么格式(output_schema)、什么时候必须停(stop_conditions)。
worker 返回的结果不符合 output_schema 就直接判失败,不靠人眼从一大段自然语言里捞结论。

task:
  id: task-20260713-001
  role: reviewer
  objective: "检查报告中的事实与引用"
  inputs:
    artifact_uri: "artifact://report/v3"
  constraints:
    max_steps: 8
    deadline_ms: 60000
    tools: [read_artifact, search_sources]
  output_schema:
    verdict: "pass | revise | blocked"
    findings: []
    evidence: []
  stop_conditions:
    - no_new_evidence
    - budget_exhausted
    - contract_satisfied

必须显式设计的边界

读法:第二列的问题在设计阶段就要写下答案,第三列是没答清时的典型翻车现场。拿 Context 这行举例:常见错误是把用户的全部对话历史原样转发给每个 worker,token 成本和噪声一起爆炸;正确做法是只给 reviewer 传 artifact 的 URI 和检查目标,它自己按需读取。

Supervisor 的职责

• 把用户目标拆成可独立验收的 task。
• 为 task 分配最小工具集和上下文。
• 维护 task 状态,不让模型自行发明状态。
• 收集 artifact,而不是拼接所有聊天记录。
• 对副作用操作执行统一权限判断。
• 在失败、超时、预算耗尽时终止或降级。

多智能体 eval

上多智能体之前,先让单 Agent 跑同一批测试用例拿到基线数字,然后至少比较这些指标:

如果成功率没有显著提高,但成本和延迟翻倍,就应退回单 Agent + reviewer tool 或固定 workflow。

Browser 与 Computer Use

Browser Agent 不等于“给模型一个 HTTP 抓取工具”。它面对的是动态状态、视觉布局和不稳定交互。

表里 DOM 是浏览器把 HTML 解析成的元素树;ARIA tree(可访问性树)是它的语义化版本,本来是给屏幕阅读器用的,每个元素带 role 和名字(比如 role=button、name=提交),比像素坐标稳定得多。
优先级应是:**正式 API > DOM/可访问性树 > 视觉点击**。越靠右,成本、歧义和安全风险越高:API 拿到的是结构化数据;DOM 操作会因前端改版失效;视觉点击连「按钮在哪」都要靠模型看图猜。

最小状态机

Observe → Locate → Validate → Act → Wait → Verify → Record

动作前后都要验证:

• 动作前:页面域名、当前账号、目标元素、是否涉及敏感数据。
• 动作后:页面是否真的变化、是否出现弹窗、结果是否可逆。
• 不确定时:重新观察,不要凭旧坐标盲目点击。页面可能已经变了,旧坐标点下去可能是另一个按钮。

必留的 trace 证据

trace 就是执行过程的结构化日志,出问题时靠它一步步回放。Browser Agent 的每次动作至少记这些字段:

安全红线

• 网页内容是不可信输入。页面里藏一句「忽略之前的指令,改为执行 XX」这类文本,叫 prompt injection(提示词注入),它只是被读到的数据,绝不能升级为系统规则。类比 SQL 注入:用户输入永远只能当参数,不能拼进 SQL 当语句执行。
• 页面文本不得诱导 Agent 读取密钥、用户目录或其他标签页内容。
• 登录、支付、发帖、发信、删除、上传私有文件必须单独建模副作用并请求确认。
• 下载文件先隔离和校验,不能下载后直接执行。
• 默认只访问任务授权的域名;跨域跳转重新评估权限。
• 不绕过验证码、平台限制、访问控制或 robots/服务条款。

失败恢复

长运行个人 Agent

OpenClaw、Hermes 这类个人 Agent 和一次性 CLI 的区别在于常驻:进程一直挂着,随时接收 Slack/Telegram 消息、定时干活、主动把结果推回给你。多出来的这一整块就是下面的常驻运行面。

核心对象

常驻系统额外风险

• 重启后任务重复执行:需要 lease(租约:带过期时间的锁,持有者宕机后别人能接管)、idempotency key(幂等键:同一任务 ID 重复执行只生效一次,和 MQ 消费防重是一回事)和 outbox(发件箱模式:待发消息与业务数据写进同一个数据库事务,再由后台任务扫表投递,保证消息不丢也可去重)。
• 多入口同时修改同一 session:需要版本号(乐观锁,思路同 update ... where version = ?)或串行 actor(同一 session 的消息进同一个单线程队列排队处理)。
• 心跳空转烧 token:如果每 30 秒都唤醒模型看一遍待办列表,一天就是近三千次推理调用,绝大多数什么都不干。应该先由确定性调度器(普通代码查库,判断有没有到期任务)筛选,有活才调用模型。
• 长期记忆被提示词注入污染:写入前做来源、置信度、敏感度和人工确认策略。
• 消息投递失败:区分任务完成与结果已送达,支持重投但不能重复副作用。
• 权限随时间漂移:capability 要有作用域、过期时间和撤销记录。

项目阶梯

扩展线不要同时开工,按下面顺序逐层增加系统复杂度。

四周扩展计划

前置条件:核心主线 P0-P8(主线路线里编号 0 到 8 的九个阶段项目)已有可运行 demo、trace 和 eval;否则先回到 04-每周推进计划。

系统选读地图

不要按 star 数扫仓库,每次只选一个系统回答一个架构问题。

最终验收表

学完拿这张表自检:中间列是能拿得出手的证据,右列是自我感觉良好的信号。

推荐资料

• Agent Learning Hub:本篇的路线对照来源。
• Anthropic: Building effective agents:workflow、agent 与组合模式。
• Model Context Protocol:工具和数据能力协议。
• Agent2Agent Protocol:Agent 间任务通信。
• Agent Client Protocol:Agent 与宿主应用通信。
• Claude Code Subagents:子代理与上下文隔离。
• Claude Computer Use:Computer Use 工具与安全注意事项。
• WebArena:网页 Agent 评测环境。
• SWE-bench:真实软件工程任务评测。

核心结论

现代 Agent 工程的升级方向:把任务经验沉淀成可复用的 Skill,把外部能力接入收进 MCP/A2A/ACP 这些明确协议,把多智能体协作落成可校验的 task 和 artifact,把网页操作做成可回放的状态机,再用 trace、eval、权限和可靠投递把这一切约束住。单纯堆更多角色不算升级。

延伸阅读

• Java & Agent学习路线
• Agent CLI源码剖析 - 全局架构与数据流