Agentic Web：当 AI 开始与其他 AI 对话时
I’m ready to translate the article for you, but I need the full text of the post (the content you’d like translated). Could you please paste the article’s body here? Once I have it, I’ll provide a Simplified‑Chinese translation while preserving the source link, formatting, markdown, and any code blocks or URLs unchanged.
当前交互模式
过去几年，我们与 AI 的大多数交互遵循相同的模式：
- 你提出问题。
- AI 回答。
无论你使用聊天机器人、编码助手还是 AI 搜索工具——结构几乎总是：
Human → AI → Answer新兴转变：AI → AI
有趣的事情正在 AI 工程领域出现。下一代系统不再仅仅设计用于回答问题；它们被设计为 完成任务。
当 AI 系统开始完成任务时，它们不可避免地需要与其他系统交互，从而引发一个引人入胜的转变：
AI 正在开始与其他 AI 对话。
这个概念有时被称为 Agentic Web（代理网络）。未来的互联网可能不再主要为人类浏览而构建，而是逐渐成为一个自主代理协作、协商并在各服务间执行操作的网络。
当今网络的工作方式
如果你想计划一次旅行，可能会这样操作：
- 打开航班搜索网站
- 比较价格
- 查看酒店网站
- 查阅评论
- 输入付款信息
每一步都需要人工注意力和决策。网络的构建假设有人坐在屏幕前，因此界面设计针对：
- 点击按钮
- 填写表单
- 滚动页面
- 比较选项
AI 代理并不需要这些界面。 它们：
- 不会滚动
- 不会慢慢阅读评论
- 不会打开 15 个标签页来比较价格
相反，它们 直接与系统交互。这一认识表明，互联网可能会朝着一种方向演进：服务不仅针对人类交互进行优化，还会针对 机器协作 进行优化。
聊天机器人 vs. 代理
| 方面 | 聊天机器人 | 代理 |
|---|---|---|
| 本质 | 被动响应 | 目标驱动 |
| 触发方式 | 等待指令 | 接收目标并自行决定实现方式 |
| 输出 | 产生文本（例如，选项列表） | 产生动作（例如，API 调用、工作流步骤） |
示例提示： “查找飞往东京的最便宜航班。”
-
聊天机器人： 返回一个选项列表。
-
代理： 可能执行如下工作流：
- 搜索航空公司 API
- 跨平台比较价格
- 检查你的日历
- 查看酒店可用性
- 优化行程
这种从生成响应到执行工作流的转变，使得具备代理特性的系统更加强大。
多代理系统的需求
一个 AI 代理无法现实地独自处理所有可能的任务。早期的尝试试图构建一个 单一的、通用的代理，但随着任务变得更加复杂，这种方法崩溃了：
- 更难管理
- 推理速度更慢
- 难以调试
- 更难扩展
解决方案： 构建 由专门化代理组成的团队，相互协作——类似于人类组织工作的方式。
典型的代理架构
Goal
↓
Planner Agent
↓
Task Decomposition
↓
Research Agent
↓
Execution Agent
↓
Critic Agent| 代理 | 角色 |
|---|---|
| Planner Agent | 解释整体目标并将其拆分为可管理的任务 |
| Research Agent | 收集相关信息或检索文档 |
| Execution Agent | 与工具、API 或外部系统交互 |
| Critic Agent | 审核输出并检查是否已实现目标；如有需要触发调整 |
这种结构类似一个小型组织：一个负责规划，另一个负责调查，另一个负责执行，最后一个负责审查。
示例工作流程：规划旅行
用户请求： “在 $1500 以下计划一次为期五天的东京之旅。”
User
↓
Personal AI Agent
↓
Travel Planning Agent
↓
Flight Pricing Agent
↓
Hotel Recommendation Agent
↓
Payment Agent- 航班定价代理： 查找航空公司选项。
- 酒店推荐代理： 搜索住宿数据库。
- 定价代理： 协商折扣或促销。
- 支付代理： 完成预订。
从用户的角度来看，整个过程看起来很简单，但在后台有多个代理协同工作以完成任务。这就是 Agentic Web 的本质。
构建代理系统的框架
从头创建此类编排系统将极其复杂。为帮助工程师，已经出现了若干框架：
- LangGraph – 用于构建具有记忆和状态的结构化代理工作流。
- CrewAI – 专注于由专门化代理组成的协作团队。
- AutoGen – 由 Microsoft 开发，使代理之间能够相互通信。
这些框架提供了 基础设施层，用于代理互联网，使开发者能够设计多个代理随时间协同动作的系统，而不是仅调用一次 LLM。
多代理协作带来的新挑战
当多个自主系统协作时，协调变得至关重要。随之而来的问题包括：
- 谁来决定计划？
- 如果两个代理意见不一致会怎样？
- 代理如何共享记忆？
- 我们如何防止无限循环？
- 如果某个代理失效会怎样？
这些挑战类似于 分布式系统 中的挑战，这意味着构建可靠的代理系统日益需要 传统软件工程实践，而不仅仅是提示工程。
Closing Thought
多代理系统的兴起暗示了 AI 与互联网未来的一个重要趋势：网络正从以人为中心的界面演变为以机器为中心的自主代理网络，这些代理能够代表我们进行规划、行动和协作。
AI的未来
与其依赖单一的超智能模型，我们可能会看到 由更小、更专门的代理组成的生态系统协同工作。
为什么这很重要
- 代理可以专精——每个代理专注于狭窄的领域。
- 工作可以并行进行——多个任务同时运行。
- 系统更易扩展——可以在不彻底改造整体架构的情况下添加新代理。
- 故障更易定位——出现故障的代理可以被识别并替换，而不会导致整个系统崩溃。
- 复杂任务变得可管理——将问题拆分为子任务，使其易于处理。
其结果不仅是更聪明的 AI；更是 组织更良好的 AI。
使用互联网方式的转变
如果这一趋势持续下去，互联网本身可能会演变为：
- 从 主要由人类导航的空间
- 到 一个代理代表我们与服务及其他代理交互的网络。
人类仍然会定义目标，但实际工作——搜索、比较、谈判、执行——可能会越来越多地在 幕后 完成。
换句话说，互联网可能会逐渐从：
人类驱动的浏览 → 代理驱动的执行
代理网络 的崛起
AI 最令人激动的变化可能并非仅来自更大的模型，而是来自 AI 系统之间的协作方式。
- 智能 分布 在由专门代理组成的网络中。
- 没有单一 AI 能完成所有任务；AI 团队共同解决问题。
如果这样的未来到来，互联网可能不再像一堆静态网站的集合……
而更像是一个 协作机器的活生生生态系统。