第十四章:Harness 工程的未来¶
前十三章介绍了 Harness 系统的当今现状:如何架构(第 1-4 章)、如何交互(第 5-8 章)、如何优化(第 9-11 章)、如何守护(第 12 章)、如何评估(第 13 章)。本章转向未来:Harness 工程将走向何方。
这不是科幻,而是基于以下证据的发展预测:
- 学术进展:GAIA、WebArena 等基准揭示了智能体能力的天花板,推动框架创新
- 工业实践:超过半数的组织已在生产环境运行智能体系统(LangChain State of Agent Engineering 调研,57.3%),积累了大量经验
- 标准化动向:NIST 于 2026 年 2 月正式发起 AI Agent 标准化倡议(CAISI 主导),标志着从混沌走向秩序
- 技术趋势:多智能体、智能体即操作系统(Agent-as-OS)、持久化智能体等新范式不断涌现
核心主题
- 智能体原生应用:从“AI 增强现有应用”到“应用由 Agent 构成”的范式转移
- 标准化演进:MCP 持续演进、NIST CAISI 标准、跨框架互操作性
- 开放问题:可靠性、长期记忆、涌现行为控制等学术挑战
本章的目标
- 识别下一个十年 Harness 工程的关键方向
- 理解标准化对工程实践的影响
- 为读者的技术选择和投资决策提供指导
14.1 智能体原生应用¶
本节探讨从 AI 增强型应用向智能体原生应用的演进,阐述智能体即操作系统的愿景、关键技术挑战以及多智能体协作的实现模式。
框架视角:Harness 是 Token 经济里的 RaaS 层
从商业模式看,智能体服务正沿 Token 即服务(TaaS)→ 智能体即服务(AaaS)→ 结果即服务(RaaS) 拾级而上,计费口径也随之从“按 Token 消耗量”转向“按价值”。Harness 工程支撑的正是最上层的 RaaS:它把“交付可信结果”这一商业承诺,落到两项可度量的交付物上——结果可验证性 与任务完成率。2026 年 7 月《北京市加快智能体引领发展若干措施》已把“发展 Token(词元)经济”“从 Token 消耗量计费转向价值计费”写入正式文本,为这一阶梯写下政策注脚。(本书只取 Harness 视角的一角,完整的商业模式讨论不在本书范围。)
1.1 从 AI 增强到智能体原生¶
当前的智能体应用大多是 AI 增强 (AI-Enhanced)的变体:
graph TB
subgraph Traditional["传统应用架构"]
A["应用业务逻辑"]
B["数据库/API"]
C["用户界面"]
A --> B
B --> C
end
subgraph Enhanced["AI增强型应用"]
D["<b>应用业务逻辑</b><br/>(主导)"]
E["<b>Agent + LLM</b><br/>(可选)"]
F["数据库/API"]
G["用户界面"]
D --> F
D --> E
E --> F
F --> G
end
subgraph Native["Agent原生应用"]
H["用户意图"]
I["<b>Agent(as OS)</b><br/>感知/推理/行动"]
J["工具层"]
K["环境/持久化"]
H --> I
I --> J
I --> K
J --> K
end
style Traditional fill:#f8f9fa
style Enhanced fill:#fff3cd
style Native fill:#d4edda
图 14-1:应用架构演进
关键差异:
| 维度 | AI 增强型 | 智能体原生型 |
|---|---|---|
| 核心驱动 | 传统代码逻辑 | 智能体推理 |
| 控制流 | 过程式/事件驱动 | 自主目标导向 |
| 适配性 | 固定的 API 契约 | 动态的能力发现 |
| 失败处理 | 异常处理 | 自我修正与重试 |
| 学习能力 | 无(非学习系统) | 有(从经验改进) |
1.2 智能体即操作系统愿景¶
智能体即操作系统(Agent-as-OS) 是智能体原生应用的终极形态。传统 OS 的职责扩展到智能体:
graph TD
APP["<b>Agent应用层</b><br/>多智能体协作 / 长期自驱 / 智能工作流"]
AOS["<b>Agent操作系统层</b><br/>Agent进程 / 上下文管理 / 工具挂载 / Agent通信 / 权限框架"]
OS["<b>操作系统层</b><br/>进程管理 / 内存管理 / 文件系统 / 通信IPC / 权限控制"]
HW["<b>硬件层</b><br/>物理计算资源"]
APP -->|"调用Agent OS服务"| AOS
AOS -->|"映射到OS原语"| OS
OS -->|"驱动硬件"| HW
style APP fill:#d4edda,stroke:#28a745,color:#000000
style AOS fill:#fff3cd,stroke:#ffc107,color:#000000
style OS fill:#e1f5ff,stroke:#42a5f5,color:#000000
style HW fill:#f8f9fa,stroke:#bbb,color:#000000
图 14-2:Agent 操作系统架构堆栈
1.2.1 传统操作系统的核心职责¶
- 进程管理:创建、调度、销毁任务
- 内存管理:分配隔离的内存空间
- 文件系统:持久化存储管理
- 通信:进程间通信(IPC)
- 权限控制:访问控制与安全
1.2.2 智能体操作系统中的对应角色¶
智能体操作系统的概念设计如下:
class AgentOS:
"""Agent操作系统概念设计"""
def __init__(self):
self.process_manager = AgentProcessManager() # 进程管理
self.memory_manager = AgentMemoryManager() # 上下文/内存管理
self.tool_filesystem = ToolFilesystem() # 工具即文件系统
self.ipc = InterAgentCommunication() # 多智能体通信
self.security = SecurityManager() # 权限和安全
async def spawn_agent(self,
objective: str,
tools: List[Tool],
context: dict = None) -> "Agent":
"""创建一个Agent进程"""
agent = Agent(
objective=objective,
tools=tools,
context=context,
os=self
)
await self.process_manager.register(agent)
return agent
async def allocate_context(self,
agent_id: str,
size_tokens: int) -> "ContextWindow":
"""为Agent分配上下文窗口(类似内存分配)"""
return await self.memory_manager.allocate(agent_id, size_tokens)
async def mount_tools(self,
agent_id: str,
tools: List[Tool]) -> None:
"""将工具挂载为"文件系统"(工具发现与调用)"""
await self.tool_filesystem.mount(agent_id, tools)
async def send_message(self,
from_agent: str,
to_agent: str,
message: str) -> None:
"""Agent间通信"""
await self.ipc.send(from_agent, to_agent, message)
async def enforce_permissions(self,
agent_id: str,
tool_name: str) -> bool:
"""权限检查(第12章的Permission Engine)"""
return await self.security.check_permission(agent_id, tool_name)
1.2.3 智能体操作系统的应用场景¶
1. 多智能体协作系统
async def collaborative_task():
"""多个智能体协作解决复杂问题"""
os = AgentOS()
# 创建专用Agent
researcher = await os.spawn_agent(
objective="研究问题背景",
tools=["search_web", "read_document"]
)
analyst = await os.spawn_agent(
objective="分析研究结果",
tools=["data_analysis", "visualization"]
)
writer = await os.spawn_agent(
objective="撰写报告",
tools=["write_document", "format_text"]
)
# Agent间通信
research_result = await researcher.execute()
await os.send_message("researcher", "analyst", research_result)
analysis = await analyst.execute()
await os.send_message("analyst", "writer", analysis)
report = await writer.execute()
return report
2. 长期自驱智能体
class AlwaysOnAssistant:
"""持久化的自驱Assistant(Heartbeat模式)"""
def __init__(self):
self.os = AgentOS()
self.persistence = PersistenceLayer()
self.heartbeat_interval = 300 # 5分钟
async def start_heartbeat(self):
"""心跳机制:定期检查待办事项"""
while True:
# 从持久化存储读取状态
state = await self.persistence.load_state()
# 检查是否有待处理的任务或消息
pending = await self.persistence.get_pending_actions()
if pending:
# 恢复智能体并继续执行
agent = await self.os.spawn_agent(
objective="处理待处理任务",
tools=state.get("tools", []),
context=state.get("context", {})
)
await agent.execute()
# 持久化智能体状态
await self.persistence.save_state(agent.state)
# 等待下一个心跳
await asyncio.sleep(self.heartbeat_interval)
# OpenClaw中的Heartbeat自驱模式是智能体操作系统的早期形态
3. 智能流程自动化
async def intelligent_workflow():
"""智能体驱动的动态工作流"""
os = AgentOS()
# 智能体自主决定下一步(不是预先定义的流程)
current_agent = await os.spawn_agent(
objective="处理客户投诉",
tools=["read_email", "access_database", "draft_response"]
)
while True:
# 智能体执行并决定下一步
action = await current_agent.decide_next_action()
if action.type == "transfer":
# 动态转交给其他智能体
current_agent = await os.spawn_agent(
objective=action.objective,
tools=action.required_tools,
context=action.context # 传递上下文
)
elif action.type == "complete":
break
elif action.type == "escalate":
# 升级到人工
break
Agent-native 架构的设计理念为智能体系统的演进指明了方向。但在实现这一愿景的过程中,系统架构师们面临着多个重大的技术挑战,这些挑战涉及持久化、可用性和与外部系统的集成。
1.3 技术挑战¶
1.3.1 上下文持久化¶
问题:传统应用数据可以持久化到数据库,但智能体的 推理状态 无法显式存储。
当前方案:
- 将上下文的关键决定点序列化存储
- 重启时重新执行推理恢复状态
- 成本:O(历史长度)
未来方向:
class PersistentContext:
"""持久化推理上下文"""
async def checkpoint(self):
"""定期保存推理检查点"""
# 不仅保存最终答案,也保存中间推理步骤
checkpoint = {
"timestamp": now(),
"reasoning_steps": self.reasoning_trace,
"decisions": self.decision_log,
"context_window": self.current_context,
"learned_facts": self.extracted_knowledge,
}
await self.storage.save(checkpoint)
async def restore(self, checkpoint_id):
"""从检查点恢复"""
checkpoint = await self.storage.load(checkpoint_id)
self.reasoning_trace = checkpoint["reasoning_steps"]
self.decision_log = checkpoint["decisions"]
# ...
1.3.2 多智能体协调¶
问题:多个智能体可能有冲突的目标或输出,如何协调?
当前方案:中央调度器(智能体操作系统)仲裁
挑战:
- 如何设计智能体间的通信协议
- 如何检测和解决冲突
- 如何确保整体系统稳定性
1.3.3 能力发现与绑定¶
问题:智能体操作系统需要动态发现可用的工具和能力
MCP(Model Context Protocol)的角色:
- 标准化工具定义
- 支持动态能力查询
- 能力协商(capability negotiation)已内置于现行规范的 initialize 握手;MCP 路线图进一步规划了 Server Cards(经
.well-knownURL 暴露服务器元数据)等特性
1.3.4 学习与自适应¶
问题:智能体操作系统中的智能体应该如何从经验学习?
两种层级的学习:
- 单体智能体学习:
- 当前 Harness 中缺失
- 未来可通过微调或检索增强学习
- 系统级学习:
- 跨智能体的知识共享
- 整个智能体操作系统的性能优化
- 需要新的架构(如中央知识库)
class AgentSystemLearning:
"""智能体操作系统级学习"""
async def share_knowledge(self,
source_agent: str,
knowledge: dict,
scope: str = "global"):
"""共享知识
scope: "global" (全系统) / "team" (同团队) / "private" (私有)
"""
await self.knowledge_store.save(
source_agent,
knowledge,
scope=scope
)
async def learn_from_failure(self,
failed_agent: str,
error: Exception,
context: dict):
"""从失败学习"""
# 1. 记录失败原因
failure_case = {
"agent": failed_agent,
"error": error,
"context": context,
"timestamp": now()
}
await self.failure_store.save(failure_case)
# 2. 其他智能体避免相同错误
similar_agents = await self.find_similar_agents(failed_agent)
for agent_id in similar_agents:
await self.notify_agent(
agent_id,
f"避免在类似场景下使用: {error}"
)
本节总结:智能体原生应用代表了 Harness 工程的终极形态——从工具调用框架演进为 自主操作系统。虽然当前还有许多技术挑战,但 OpenClaw 的自驱模式和 MCP 标准已经指向这个方向。
2. 标准化演进¶
本节阐述智能体系统的标准化方向,包括 MCP 的技术演进、NIST 标准化倡议、框架间互操作性以及智能体协议栈的完整生态。
2.1 MCP 的演进路线图¶
MCP(Model Context Protocol)采用日期版本号;当前官方 latest 路径指向 2026-07-28,上一修订版为 2025-11-25。由于协议仍在迭代,正文只描述当前规范中可确认的机制,并把未来能力作为示意性方向处理。
MCP 当前版本:
核心特性:
- 工具定义的通用格式(JSON Schema)
- 客户端-服务器通信模型
- 支持 stdio(本地子进程)和 Streamable HTTP(远程服务)两种传输层
- 进度、取消、日志等通用能力可配合长时操作使用
- 动态工具注册(通过
notifications/tools/list_changed通知)
当前限制:
- 工具定义虽支持动态注册,但大多数实现仍以启动时静态注册为主
- 缺乏正式的智能体间通信标准
- 企业级特性(审计、SSO、网关)仍在规划中
注:早期版本曾使用 SSE(Server-Sent Events)作为独立传输层,已在 2025-03-26 版本中废弃,统一为 Streamable HTTP。
MCP 下一代演进:
特性 1:动态能力协商
以下“动态能力协商”是 Harness 可能采用的扩展设计,用来说明未来方向;它不是当前 MCP 规范或官方 SDK 中的 API:
# MCP 下一代 - 动态能力协商
@dataclass
class CapabilityQuery:
"""智能体查询可用能力"""
agent_id: str
required_capabilities: List[str] # ["read_file", "write_file"]
optional_capabilities: List[str]
resource_constraints: dict # {"memory_mb": 512, "timeout_sec": 30}
@dataclass
class CapabilityOffer:
"""服务提供的能力"""
capabilities: List[ToolDefinition]
cost: dict # {"latency_ms": 100, "cost_usd": 0.001}
constraints: dict # {"rate_limit": 100_per_hour}
async def negotiate_capabilities(query: CapabilityQuery) -> CapabilityOffer:
"""动态协商能力
LLM不再依赖启动时加载的工具列表,而是在运行时查询可用能力
"""
pass
应用场景:
# 示例:智能体需要处理PDF,检查是否有能力
query = CapabilityQuery(
agent_id="data-analyzer",
required_capabilities=["read_pdf", "extract_text"],
optional_capabilities=["ocr_scan"],
resource_constraints={"memory_mb": 256}
)
# MCP 服务返回可用的实现
capabilities = await mcp_server.negotiate(query)
if "read_pdf" in capabilities:
# 使用该能力
pdf_content = await agent.call_tool("read_pdf", file_path="doc.pdf")
else:
# 降级方案:上传到云服务
await agent.call_tool("upload_to_cloud", file_path="doc.pdf")
特性 2:增强的持久化会话与流式通信
MCP 2025-11-25 通过 Streamable HTTP 支持 HTTP POST/GET、可选 SSE 流式响应、会话 ID、恢复与重投递等机制;2026-07-28 移除了协议级会话(Mcp-Session-Id)、GET 端点与 SSE 重投递,订阅推送改由 subscriptions/listen 承担。下面的“增强持久化会话”是概念示意,不代表当前规范已有同名 API:
# MCP 下一代 - 增强持久化会话
class StreamingMCPSession:
"""支持流式通信的持久化会话"""
async def open_stream(self, agent_id: str) -> Stream:
"""打开持久化流"""
# 保持连接开放,支持实时推送(而不仅是请求-响应)
pass
async def push_event(self, event: Event):
"""服务器主动推送事件到智能体"""
# 例:外部事件到达,直接推送给Agent
# 当前MCP通过SSE支持服务端推送,但缺乏完整的事件订阅机制
pass
async def bidirectional_tool_call(self):
"""工具可以回调Agent"""
# 当前:智能体 -> 工具(单向为主)
# 下一代:工具 -> 智能体(完整的反向调用支持)
# 应用:工具需要智能体决策时
pass
特性 3:智能体间通信标准
实现如下:
# MCP 下一代 - 智能体间通信
@dataclass
class AgentMessage:
from_agent: str
to_agent: str
message_type: str # "request", "response", "event"
content: dict
correlation_id: str # 追踪相关消息
class AgentProtocolCommunication:
"""未来 MCP 或 A2A 类协议可能支持的智能体间通信"""
async def send_message(self, msg: AgentMessage) -> None:
"""智能体A发送消息给智能体B"""
# 若未来 MCP 或 A2A 类协议提供标准消息路由,可在此接入
pass
async def broadcast_event(self, event: dict, target_group: str) -> None:
"""广播事件到智能体组"""
# 类似发布-订阅
pass
async def request_capability(self,
requesting_agent: str,
capability: str,
params: dict) -> Any:
"""跨智能体能力请求"""
# 智能体A要求智能体B执行某个能力
pass
应用例:多智能体协作
async def collaborative_data_analysis():
"""多智能体协作分析(MCP下一代版本支持)"""
# 智能体A(爬虫)向智能体B(分析员)发送数据
message = AgentMessage(
from_agent="scraper_agent",
to_agent="analyst_agent",
message_type="request",
content={"data": scraped_data, "analysis_type": "statistical"}
)
await mcp_server.send_message(message)
# 智能体B接收并处理
result = await analyst_agent.process_request(message)
# 智能体B响应智能体A
response = AgentMessage(
from_agent="analyst_agent",
to_agent="scraper_agent",
message_type="response",
content=result
)
await mcp_server.send_message(response)
MCP 演进时间线: 官方规范使用日期版本号发布。下面仅保留确定的当前版本,并把后续方向写成待观察事项,避免把社区讨论或预测写成官方路线图:
timeline
title MCP 演进时间线
2025-11 : 上一稳定版 : 2025-11-25
2026-07 : 当前稳定版 : 2026-07-28
后续版本 : 待官方发布 : 关注传输、授权、安全和企业集成
长期方向 : 待生态验证 : 跨框架互操作
图 14-3:MCP 标准演进路线图
2.2 NIST AI 智能体标准化¶
NIST 的 CAISI(Center for AI Standards and Innovation)于 2026 年 2 月 17 日正式发起 AI Agent 标准化倡议,聚焦三大战略支柱:行业标准制定与国际标准话语权、开源协议社区发展、以及智能体安全与身份研究。其目标是建立 跨行业的智能体系统标准。
标准化可能覆盖的关键领域
下面的能力等级、检查清单和任务集合是本书基于 NIST 倡议方向抽象出的示意性评估框架,不是 NIST 已发布的官方合规 API、能力等级或标准任务集。实际标准、术语和时间表应以 NIST 后续正式发布为准。
2.2.1 功能分类与能力等级¶
分类如下:
Level 1: 基础工具调用
- 单步工具调用
- 简单参数
- 示例:单个文件操作、查询API
Level 2: 多步推理
- 多步工具链
- 错误恢复
- 示例:复杂数据分析、问题求解
Level 3: 自适应规划
- 动态工具选择
- 目标分解
- 示例:长期项目规划、复杂系统设计
Level 4: 多智能体协调
- 智能体间通信
- 分布式执行
- 示例:组织协作、跨域问题解决
Level 5: 持久自主系统
- 长期记忆
- 自主学习
- 示例:智能体操作系统、完全自驱助手
2.2.2 安全性基线¶
评估方案如下:
class AgentSecurityBaselineExample:
"""示意性的智能体安全基线,不代表 NIST 已发布标准"""
@staticmethod
def evaluate_system(agent_system) -> SecurityReport:
"""评估系统的安全合规性"""
report = SecurityReport()
# Category 1: 工具调用安全
report.tool_safety = {
"dangerous_command_detection": True, # 12.3
"path_validation": True, # 12.4
"parameter_validation": True,
"rate_limiting": True,
}
# Category 2: 隐私保护
report.privacy = {
"data_minimization": check_data_minimization(agent_system),
"encryption_at_rest": check_encryption(agent_system),
"access_control": check_access_control(agent_system),
"audit_logging": check_logging(agent_system),
}
# Category 3: 可靠性
report.reliability = {
"failure_handling": check_error_handling(agent_system),
"recovery_capability": check_recovery(agent_system),
"health_monitoring": check_monitoring(agent_system),
"graceful_degradation": check_degradation(agent_system),
}
# Category 4: 可解释性
report.interpretability = {
"decision_traceability": check_traceability(agent_system),
"reasoning_transparency": check_transparency(agent_system),
"human_oversight": check_oversight(agent_system),
}
# 合规评分
report.compliance_score = compute_score(report)
return report
2.2.3 性能基准的标准化¶
示意性任务集合如下:
graph TD
A["示意性智能体任务集合"] --> B["<b>信息检索任务</b><br/>20个"]
A --> C["<b>事务处理任务</b><br/>20个"]
A --> D["<b>推理任务</b><br/>20个"]
A --> E["<b>协作任务</b><br/>20个"]
B --> B1["单源查询"]
B --> B2["多源综合"]
B --> B3["事实验证"]
C --> C1["<b>单步操作</b><br/>购买、预订"]
C --> C2["<b>多步流程</b><br/>订单到支付"]
C --> C3["异常处理"]
D --> D1["数学问题"]
D --> D2["逻辑推理"]
D --> D3["因果分析"]
E --> E1["多智能体任务分解"]
E --> E2["冲突解决"]
E --> E3["知识共享"]
style A fill:#e3f2fd,stroke:#1565c0
style B fill:#f3e5f5,stroke:#7b1fa2
style C fill:#fff3e0,stroke:#ffb74d
style D fill:#e8f5e9,stroke:#388e3c
style E fill:#fce4ec,stroke:#c2185b
标准化的长期目标已经清晰,但当前生态中各个框架各自为政,形成了事实上的碎片化。实现框架间的互操作性是推进标准化的重要一步,需要在工具定义、权限模型和通信协议等多个层面进行统一。
2.3 框架间互操作性¶
2.3.1 现状:碎片化¶
情景如下:
graph LR
A["Claude Code"] --> B["<b>各有各的工具定义</b><br/>权限模型、沙箱<br/>难以混用或迁移"]
C["OpenClaw"] --> B
D["LangChain"] --> B
E["Anthropic SDK"] --> F["孤立"]
style B fill:#ffcccc,stroke:#c62828,stroke-width:2px
style F fill:#ffcccc,stroke:#c62828,stroke-width:2px
2.3.2 MCP 演进 + NIST 标准的未来¶
架构如下:
graph TD
A["应用"] --> B["智能体框架1"]
A --> C["智能体框架2"]
A --> D["智能体框架3"]
B --> E["<b>MCP 标准通信协议</b><br/>对齐NIST倡议"]
C --> E
D --> E
E --> F["<b>共享工具库</b><br/>可互换"]
E --> G["<b>标准化评估</b><br/>可对标"]
E --> H["<b>通用智能体市场</b><br/>跨框架迁移"]
style A fill:#fff9c4
style B fill:#c8e6c9
style C fill:#c8e6c9
style D fill:#c8e6c9
style E fill:#bbdefb,stroke:#1565c0,stroke-width:2px
style F fill:#f8bbd0
style G fill:#f8bbd0
style H fill:#f8bbd0
2.3.3 互操作性的代码示例¶
示例如下:
# MCP + NIST 标准下的互操作性
from mcp import MCPClient, CapabilityQuery
class FrameworkAgnosticAgent:
"""框架无关的智能体(未来)"""
def __init__(self):
self.mcp_client = MCPClient()
async def use_tool(self, tool_name: str, **kwargs):
"""使用任何通过MCP暴露的工具,无论来自哪个框架"""
# 1. 查询工具能力
tool_spec = await self.mcp_client.query_tool(tool_name)
# 2. 验证NIST安全基线
assert tool_spec.is_nist_compliant()
# 3. 调用工具(框架无关)
result = await self.mcp_client.call_tool(
tool_name=tool_name,
args=kwargs,
timeout=tool_spec.recommended_timeout
)
return result
async def migrate_to_new_framework(self, new_framework_name: str):
"""迁移到新框架
由于使用了标准化工具和通信,迁移成本大幅降低
"""
# 1. 导出当前智能体的定义(MCP标准格式)
agent_definition = await self.export_mcp_definition()
# 2. 在新框架中导入
new_agent = await new_framework.import_agent(agent_definition)
# 3. 由于工具定义标准化,不需要重新绑定工具
return new_agent
2026-04-09 GA 的 Anthropic Cowork 是该方向的早期产品形态:跨工具(Claude Code、Claude.ai、第三方 IDE)共享 skill/plugin 与 MCP 配置,可视为“Harness 配置层”的标准化尝试。详见附录 C 的 2026-05 时效快照。
2.4 从技术标准到行业生态¶
标准化的涟漪效应
graph TD
A["MCP 演进 + NIST标准"] --> B["工具市场化"]
A --> C["Agent认证体系"]
A --> D["供应链标准化"]
A --> E["职业角色出现"]
B --> B1["可交易的预训练工具包"]
B1 --> B2["金融智能体工具集"]
B1 --> B3["医疗智能体工具集"]
C --> C1["未来标准化智能体可降低规制行业准入成本"]
C1 --> C2["医疗诊断Agent需满足行业监管和安全评估要求"]
D --> D1["LLM提供商"]
D1 --> D2["Harness框架"]
D2 --> D3["工具提供商"]
D3 --> D4["形成成熟的产业链"]
E --> E1["Agent工程师成为正式职位"]
E1 --> E2["需要NIST/ISO认证培训"]
style A fill:#e3f2fd,stroke:#1565c0,stroke-width:2px
style B fill:#fff3e0
style C fill:#f3e5f5
style D fill:#e8f5e9
style E fill:#fce4ec
从推演到现实:政策层面的落地
上面的涟漪效应曾长期停留在推演阶段,但 2026 年 7 月北京市发布的 《北京市加快智能体引领发展若干措施》(京发改〔2026〕1185 号)已经把其中几条写进了正式文件:
- 职业角色被正式命名:措施第三条写入“前沿部署工程师(FDE)”,与上图预测的“Agent 工程师成为正式职位”直接对应;
- 工具市场与互联标准入政策:第二条提出建设“智能体技能市场”,并要求推广智能体互联协议(AIP)等智能体互联的关键国家标准与行业标准,与 14.2.5 的协议栈演进同向;
- 术语进入官方文本:同样在第二条,“驾驭层工程(Harness Engineering)”——本书的核心概念与中文译名——被逐字写入政策原文(“支持创新主体实施驾驭层工程(Harness Engineering)……”)。
这份文件的意义不在于某一条具体条款,而在于它标志着 Harness 工程正从技术社区的实践共识,进入产业政策与标准体系的视野。对 Harness 工程师而言,这既是概念被主流承认的信号,也预示未来的接口、身份、权限与互联标准,会越来越多地由公共标准而非单一厂商来定义。
2.5 智能体协议栈的完整版图¶
MCP 解决了“智能体如何调用工具和访问上下文”的问题,但智能体生态的完整通信需求远不止于此。下面列出若干常见方向,成熟度和治理归属应以各项目官方资料为准:
| 协议 | 职责 | 发起方 | 状态 |
|---|---|---|---|
| MCP | 智能体 ↔ 工具/数据源 | Anthropic 发起,开放规范维护 | 生产采用中 |
| A2A | 智能体 ↔ 智能体 | Google 等生态参与 | 早期采用 |
| AG-UI | 智能体 → 前端 UI(事件流) | CopilotKit 开源 | 社区驱动 |
| A2UI | 智能体 → 声明式 UI(JSON 描述) | 提案阶段 |
这些协议和项目体现了智能体通信从私有集成走向开放规范的趋势,但治理结构和版本状态变化很快,工程选型时应直接核对各官方规范页面。
对 Harness 工程师而言,这意味着:
- MCP 仍是 Harness 层最核心的协议,负责工具调用和数据访问
- A2A 将影响多智能体编排的实现方式:当前基于私有消息传递的编排(如第 8 章所述),未来可能迁移到标准化的 A2A 协议上
- AG-UI/A2UI 影响前端集成:智能体的中间状态和结果如何呈现给用户,将有标准化的事件流格式
- Harness 需要成为协议网关:在不同协议之间做翻译和路由,而非只支持单一协议
2.6 专用应用协议:另一条标准化路径¶
虽然 MCP 已成为重要的开放协议,但复杂 IDE 工作流仍可能需要专用应用协议来表达编辑、审批、会话和 UI 状态。以下内容是概念化架构草图,不代表任何厂商的官方 API。
2.6.1 为何拒绝 MCP¶
在大型代码生成或 IDE 深度集成项目中,直接把 MCP 当作唯一基础协议可能遇到表达力限制:
MCP 的工具模型(tool-oriented) 设计优秀,但缺乏表达 IDE 工作流的能力:
- MCP 聚焦“调用工具获取结果”的请求-响应模式
- IDE 工作流需要:流式代码 diff、多轮审批流程、持久会话管理、双向交互
- MCP 缺乏这些原语的标准化定义,导致每个 IDE 集成都要自行扩展
2.6.2 专用应用协议的设计¶
一种可行设计是采用 JSON-RPC 双向通信 模型,并定义面向 IDE 的核心原语:
1. Items (原子 I/O 单位)
- 具有生命周期的可执行单元
- 支持流式推送(如代码 diff 的增量推送)
- 支持元数据和关联的 approval 对象
2. Turns (用户交互组)
- 单个用户操作对应的 Items 集合
- 原子性提交或回滚
- 支持多轮交互的会话聚合
3. Threads (持久会话)
- 跨越多轮用户交互的 durable session
- 完整的消息历史和执行状态持久化
- 支持长期的智能体决策追踪
2.6.3 服务端请求¶
与普通工具调用不同,IDE 专用协议通常需要支持 agent 暂停后请求用户批准:
{
"method": "request_approval",
"params": {
"turn_id": "turn_123",
"action": "apply_changes",
"changes": {...},
"rationale": "..."
}
}
这在 IDE 交互、高风险操作、长期规划修正中至关重要。
2.6.4 战略意义¶
这类专用协议的设计动机表明:
- MCP 不是全能的:工具调用的标准化已足够,但丰富的 IDE 集成需要不同的协议
- 标准化是渐进的:不同的协议面向不同的 use case,最终会形成分层的协议栈
- Harness 工程师需要多协议思维:未来系统可能同时使用 MCP、A2A 和面向 IDE/UI 的专用协议
本节总结:标准化(MCP 持续演进、NIST CAISI 倡议)将 Harness 工程从“野生西部”转变为“规范产业”。对工程师而言,意味着更少的碎片化、更强的可移植性、更高的行业认可度。对企业而言,意味着风险降低、成本优化、生态互联。
3. 开放问题¶
即使有了成熟的框架、完善的评估、严格的安全防护,智能体系统仍面临深层的、可能需要多年研究才能解决的问题。
本节讨论六大开放问题:可靠性的理论上限、长期记忆与目标保持、多智能体系统的涌现行为控制、智能体安全的攻防升级、成本效率与性能的帕累托权衡、以及 Harness 假设过时的困境。
3.1 可靠性的理论上限¶
3.1.1 可靠性问题陈述¶
给定一个 LLM(能力有限),通过工具扩展能力。 最终的系统可靠性有上限吗?
当前现状:
- 多步推理和工具链越长,错误累积越明显
- 同一系统在简单任务和复杂任务上的可靠性差距可能很大
- 公开排行榜数据变化较快,具体数字应以基准官网和模型供应商当前报告为准
理论问题:
- 是否存在一个 k,使得 k 步推理后成功率→0?
- 如何从根本上提升长链推理的可靠性?
- 或者,Agent 应该避免长链推理,转为交互式设计?
3.1.2 研究方向¶
可靠性研究框架的参考实现:
class ReliabilityFramework:
"""可靠性研究框架"""
@staticmethod
def theoretical_analysis():
"""理论分析"""
# 1. 建立可靠性的数学模型
# 2. 证明在某些条件下的上下界
# 3. 识别提升可靠性的关键点
# 例:能否通过多数投票提升可靠性?
single_agent_reliability = 0.6
n_agents = 3
from math import comb
ensemble_reliability = sum(
comb(3, k) * (0.6**k) * (0.4**(3-k))
for k in range(2, 4)
) # 多数投票时的可靠性
print(f"单Agent可靠性: {single_agent_reliability}")
print(f"3-Agent集成: {ensemble_reliability}")
@staticmethod
def empirical_evaluation():
"""实证评估"""
# 在GAIA基准上评估多步推理的可靠性衰减
# 绘制"推理深度 vs 成功率"的曲线
pass
3.2 长期记忆与目标保持¶
3.2.1 长期记忆问题陈述¶
现有 Agent 使用的上下文窗口虽已显著扩展,但仍然是有限的短期窗口;不同模型、账号权限和供应商界面的上限需要按官方模型目录确认。 如何让智能体维持长期记忆并在多天/月的时间尺度上保持目标?
3.2.2 当前方案的局限¶
当前短期内存实现的局限性示例:
# 当前方案:上下文管理
class ShortTermMemory:
"""短期上下文(当前实现)"""
def __init__(self):
self.context_window = 200_000 # 示例值;按实际模型可调到 1_000_000
self.history = []
def add(self, item):
self.history.append(item)
# 当超出限制时,丢弃早期项
if total_tokens() > self.context_window:
self.history.pop(0)
# 问题:长期信息丢失,无法维持跨天的目标
3.2.3 理想的长期记忆系统¶
代码示例如下:
from dataclasses import dataclass
from datetime import datetime
@dataclass
class MemoryItem:
content: str
importance_score: float # 1-10
timestamp: datetime
retrieval_count: int # 被检索次数
last_accessed: datetime
relationships: List[str] # 与其他记忆的关联
class LongTermMemorySystem:
"""长期记忆系统(理想版本)"""
async def store(self, item: MemoryItem):
"""存储记忆"""
# 1. 重要性评估:是否值得长期保留
if item.importance_score > threshold:
await self.long_term_store.save(item)
async def retrieve(self, query: str) -> List[MemoryItem]:
"""检索相关记忆"""
# 1. 向量相似性搜索
# 2. 时间衰减:距今越近的记忆权重越高
# 3. 检索频率:常被访问的记忆优先
decay_factor = exp(-days_since_access / half_life)
recency_score = item.retrieval_count * decay_factor
return sorted_by(recency_score)
async def consolidate(self):
"""记忆整合(类似睡眠)"""
# 周期性地对记忆进行:
# 1. 去重(移除冗余记忆)
# 2. 总结(将相关记忆聚类摘要)
# 3. 关联(找出跨时间的因果关系)
pass
async def maintain_goal(self, goal: str):
"""维持长期目标"""
# 定期检查:目标是否仍然相关
# 更新:中间里程碑的进展
# 适应:根据新信息调整目标
current_state = await self.assess_goal_progress(goal)
if current_state.progress_stalled:
# 重新规划
new_plan = await self.replan(goal)
elif current_state.environment_changed:
# 适应新环境
await self.adapt(goal, current_state)
3.2.4 技术挑战¶
- 存储成本:长期记忆的向量化和检索成本
- 一致性:多智能体系统中的记忆一致性
- 遗忘:何时有意遗忘,以防止记忆过载
- 隐私:长期存储敏感信息的风险
3.3 涌现行为与控制¶
3.3.1 涌现行为问题陈述¶
当多个智能体交互时, 整个系统可能出现非预期的涌现行为 (Emergent Behavior)。
3.3.2 案例:多智能体竞争¶
示例如下:
class EmergentBehaviorExample:
"""涌现行为案例"""
async def scenario_auction():
"""竞拍场景中的涌现行为"""
# 初始设计:每个Agent独立报价,最高价获胜
agents = [BiddingAgent(budget=1000) for _ in range(3)]
# 预期:平均成交价~500-600
# 实际:可能出现以下涌现行为
# 1. 恶性竞争:价格螺旋上升到1000+(超过价值)
# 2. 串谋:多个Agent协调压价
# 3. 市场操纵:一个强Agent驱逐其他竞争者
final_price = await conduct_auction(agents, item_value=500)
# 系统无法预测final_price具体是多少
3.3.3 解决方向¶
方案如下:
class EmergentBehaviorControl:
"""涌现行为控制"""
@staticmethod
def mechanism_design():
"""机制设计"""
# 不是事后修复涌现行为,而是事前设计机制
# 使得个体最优 = 系统最优(激励兼容)
# 例:Vickrey竞拍(次高价机制)
# 激励诚实竞价,防止恶性竞争
pass
@staticmethod
async def runtime_monitoring():
"""运行时监控与干预"""
while True:
# 监控系统行为指标
metrics = await measure_system()
# 检测异常
if metrics.price_volatility > threshold:
# 触发干预:临时暂停、改变规则等
await system.intervene("high_volatility_detected")
@staticmethod
def formal_verification():
"""形式化验证"""
# 使用模型检验等形式化方法
# 证明在某些条件下不会出现特定涌现行为
pass
3.4 智能体安全的攻防升级¶
3.4.1 安全攻防问题陈述¶
随着智能体能力提升, 安全防护需要持续进化。攻击者可能:
- 发现新的 Harness 漏洞
- 当前的路径校验可能被新编码方式绕过
- 新的危险命令组合出现
- 提示注入进化
3.4.2 防守策略的展望¶
框架示例如下:
class AdaptiveSecurityFramework:
"""自适应安全框架"""
async def red_team_simulation(self):
"""红队模拟"""
# 定期用对抗性示例测试系统
# 发现新的攻击方式
adversarial_cases = [
"新的编码方式",
"符号链接变体",
"权限提升新向量",
"提示注入变体"
]
for case in adversarial_cases:
result = await test_defenses(case)
if result.bypassed:
# 更新防护
await update_guardrails(case)
async def zero_knowledge_verification(self):
"""零知识验证"""
# 验证工具输出的有效性,无需信任工具
# 例:验证计算正确性而不重新计算
tool_output = await tool.execute()
verified = await zkproof.verify(tool_output)
if not verified:
raise SecurityError("Tool output failed ZK verification")
3.5 成本效率的帕累托前沿¶
3.5.1 成本效率问题陈述¶
成功率、响应时间、成本之间无法同时优化,存在帕累托权衡。
graph TD
A["帕累托权衡三角"]
B["成功率 ↑"]
C["廉价 ←"]
D["→ 快速"]
A --- B
A --- C
A --- D
B -.-|"高成功率 + 快速 = 高成本"| D
C -.-|"廉价 + 高成功率 = 慢"| B
D -.-|"快速 + 廉价 = 低成功率"| C
style A fill:#fff9c4,stroke:#ffb74d,stroke-width:2px
style B fill:#e8f5e9
style C fill:#e3f2fd
style D fill:#ffebee
3.5.2 权衡问题¶
示例代码如下:
class ParetoFrontier:
"""成本效率的帕累托前沿"""
@staticmethod
def characterize_frontier():
"""描述帕累托前沿"""
scenarios = [
{
"name": "低成本",
"model": "Llama 4 Scout",
"success_rate": 0.70,
"cost_per_task": 0.001,
"latency_sec": 3.0
},
{
"name": "均衡",
"model": "Claude Haiku 4.5",
"success_rate": 0.85,
"cost_per_task": 0.01,
"latency_sec": 2.0
},
{
"name": "高精度",
"model": "Claude Sonnet 4.6",
"success_rate": 0.93,
"cost_per_task": 0.05,
"latency_sec": 5.0
}
]
# 问题:如何选择?
# 答案:取决于业务KPI(容忍的成本/延迟/准确度权衡)
return scenarios
@staticmethod
async def adaptive_routing():
"""自适应路由"""
# 根据任务特征和系统状态,动态选择最优模型
for task in incoming_tasks:
# 1. 估计任务难度
difficulty = await estimate_difficulty(task)
# 2. 选择合适的模型
if difficulty == "easy":
model = "Llama 4 Scout" # 廉价
elif difficulty == "medium":
model = "Claude Haiku 4.5" # 均衡
else:
model = "Claude Sonnet 4.6" # 精确
result = await run_with_model(task, model)
3.6 Harness-as-Assumption 困境:何时该简化¶
3.6.1 问题陈述¶
本书前 13 章一直在讲 如何往 Harness 里加东西——加沙箱、加 guardrail、加重试、加压缩、加审计。但有一个反向问题同样关键: 什么时候该把已经加进去的东西拿掉?
每一个 Harness 组件——每一次工具重试、每一段上下文压缩、每一道权限护栏、每一个结构化输出校验——本质上都在编码一个隐含假设: “模型自己做不到这件事,所以基础设施必须替它兜底。”
这个观察被 Anthropic 在 2026 年的 Harness design for long-running application development 一文中明确化:
"every component in a harness encodes an assumption about what the model can't do on its own, and those assumptions are worth stress testing."
随着模型能力快速演进,这些被编码的假设会过期。一个为弱模型设计的 Harness,在强模型上会变成 不必要的开销、延迟和复杂度——更糟的是,它甚至可能限制强模型本来能做到的事。
3.6.2 案例:Anthropic 的 sprint construct 移除¶
Anthropic 给出了一个具体案例:
- Opus 4.5 时代:为了防止 agent 在长任务中“过度自我表扬”,引入了 sprint construct(把长任务切成 sprint,每个 sprint 末尾用独立 evaluator 验证)
- 升级到 Opus 4.6:原文判断“模型的原生能力已有充分理由相信不再需要这种分解”,于是移除了该组件
- 移除后的 V2 驭具:在另一项同等复杂度的应用构建任务(DAW 音乐工作站)上用时约 3 小时 50 分、成本约 \(125**;作为对照,完整驭具 + Opus 4.5 构建复古游戏编辑器用时 6 小时、成本约 **\)200。注意两次运行的任务与模型都不同,降幅不能单独归因于移除 sprint construct——但它体现了“随模型变强而精简驭具”带来的开销下降
如果没有人主动审视这个组件是否仍然必要,团队会持续为一个已经无效的假设付钱。
3.6.3 为什么是一个未解的开放问题¶
简化听起来是常识,但实践中难做到:
- 缺少“哪个假设还有效”的可观测信号:移除一个 Harness 组件需要确认它的失败率在新模型下足够低。但 Harness 的失败被 Harness 自己吸收掉了——guardrail 拦下的注入、retry 救回的瞬时失败、validator 挡下的格式错——这些都不会在常规 metric 里出现,因而无法直接看到“已经多久没救场了”
- 复合效应难以解耦:A 组件的简化可能让 B 组件的负载上升。需要 factorial(模型 × Harness 配置)实验,运行成本高
- 长尾回归风险:移除一个 guardrail 后,新模型在 99% 任务上 OK,但 1% 长尾任务上发生严重失败,单次代价可能远大于保留 guardrail 的固定开销
- 组织惯性:Harness 通常是多个团队、多次事故后的层层堆积,很少有人能完整说出“为什么这一段还在”
3.6.4 研究方向¶
class HarnessAssumptionAudit:
"""Harness 假设有效性的审计框架"""
async def shadow_ablation(self, component_to_remove, n_tasks=1000):
"""影子实验:在生产流量上并行运行 baseline 与 ablated 版本"""
baseline = await run(full_harness, tasks)
ablated = await run(
harness.without(component_to_remove),
tasks
)
return {
"success_delta_pp": ablated.success - baseline.success,
"cost_delta_pct": (ablated.cost - baseline.cost) / baseline.cost,
"long_tail_failure_rate": ablated.tail_failures,
# load_bearing_score 接近 0 → 该组件已可移除
"load_bearing_score": baseline.success - ablated.success,
}
async def factorial_evaluation(self, models, harness_configs):
"""因子化评估:识别哪些干预是'模型相关'的"""
# 一些 Harness 组件对所有模型都有效 → 应保留
# 一些组件只对弱模型有效 → 强模型升级时应移除
# 一些组件反而损害强模型 → 应紧急移除
...
async def meta_monitoring(self):
"""元监控:追踪'哪些 Harness 干预还在救场'"""
# 对每个 guardrail/validator/retry, 记录:
# - 多久没有触发过(组件可能已无效)
# - 触发后挽救的失败类型(组件还在防御什么)
# - 触发对成本的开销(组件是否值)
...
理想的 Harness 不是 单调增长的脚手架,而是 持续自问“哪些控制还需要”的自适应系统。学术综述 Agent Harness Engineering: A Survey(TMLR 投稿中,2026-05)将这个问题列为五大长期开放问题之一,并提出“adaptive simplification”作为长期目标。这一方向与本书 14.2 节“标准化演进”互补——前者关注实现层的精简, 后者关注协议层的趋同。
本节总结:这些开放问题代表了 Agent 工程的科学边界。解决它们需要跨越工程、数学、经济学的多学科合作,可能需要十年或更长时间。但正是这些挑战驱动了该领域的创新和进步。
4. 本章小结¶
本章展望了 Harness 工程的未来发展方向,以下是三条关键道路的阐述。
4.1 三条未来的道路¶
Harness 工程的未来不是单一方向,而是三条相互交织的道路:
道路 1:智能体原生应用¶
从 “AI 增强现有应用” 到 “应用由 Agent 构成”
标志:智能体即操作系统(Agent-as-OS)、多智能体协作、持久化自驱智能体
工程影响:
- 架构从 C/S 转为 Agent-OS
- 开发从过程式转为目标驱动式
- 测试从单元测试转为行为验证
时间表(本书判断):若可靠性、成本和标准化继续推进,2026-2028 年将以小规模应用为主,2030 年代可能主流化
道路 2:标准化演进¶
从 “各框架各自为战” 到 “统一的生态”
标志:MCP 持续演进、NIST CAISI 标准、跨框架互操作
工程影响:
- 工具可复用(一次编写,多框架使用)
- 人员可流动(技能可迁移)
- 产业可协同(供应链形成)
时间表:2026 年 NIST 推进调研、工作坊和标准化协作;互操作性框架、合规要求和企业采用节奏仍以官方后续发布和行业验证为准
道路 3:基础研究突破¶
从 “启发式工程” 到 “理论驱动设计”
标志:可靠性理论、长期记忆机制、涌现控制
工程影响:
- 更智能的自适应系统
- 更可预测的行为
- 更高的鲁棒性
时间表:进行中,持续多年
4.2 工程师的决策指南¶
当前阶段¶
现在做什么:
- 深化当前框架的掌握(Claude Code、OpenClaw 等)
- 实现完整的安全防护(第 12 章)
- 建立评估基线(第 13 章)
- 关注 MCP 规范演进,为适配做准备
不要过早投入:
- 多智能体系统(标准未定)
- 长期记忆系统(仍在研究)
- 智能体即操作系统(Agent-as-OS)实现(为时过早)
中期方向¶
积极探索:
- MCP 新版本迁移
- 跟踪 NIST AI Agent 标准化倡议与自愿指南
- 多智能体协作原型
- 框架间互操作性
投资重点:
- 标准化工具库(未来易复用)
- 评估框架完善(未来易对标)
- 文档和培训(人员易流动)
长期视野¶
准备就绪:
- 迎接 Agent-native 范式
- 参与标准制定
- 投资基础研究人才
4.2 反思:工程的本质¶
本书从架构、优化、安全、评估四个维度深入 Harness 系统。但在更高的层面,这些都是为了回答一个根本问题:
如何让 AI 系统可靠、安全、有效地扩展人类的能力?
这不是纯技术问题,而是涉及设计哲学、伦理、经济学的综合问题:
- 设计:Agent-OS 的架构应该如何演进?
- 伦理:自主智能体的责任边界在哪里?
- 经济:谁来为失败负责?谁收益?
- 社会:Agent 工作的崛起如何影响就业?
4.3 给读者的建议¶
对工程师¶
- 打好基础:掌握第 1-8 章的架构和交互原理
- 追求深度:选择一个维度(安全、性能、评估)深研
- 保持学习:每半年评估一次技术栈是否仍是最佳选择
- 参与社区:在 MCP、NIST 标准讨论中发出声音
对技术管理者¶
- 投资培训:Agent 工程是新领域,需要系统培训
- 建立标准:参考本书的架构、安全、评估建议
- 平衡创新与稳定:不要过早追逐最新特性,但要为未来规划
- 关注人才:优秀的 Agent 工程师会越来越稀缺
对企业领导¶
- 认识价值:本书判断,智能体系统将成为 2026 年及以后的重要竞争能力
- 评估风险:安全和可靠性不是可选的
- 规划投资:3-5 年的时间跨度考虑 Agent 策略
- 拥抱开放:支持标准化和生态建设,长期有利
4.4 结语¶
《智能体 Harness 工程指南》记录的是 Harness 工程刚刚站稳为一门独立工程学科的这个阶段。它的特征是:
- 大模型已经足够强大(Claude Opus 5 / Sonnet 5、GPT-5.6、Llama 4 等当代旗舰)
- Harness 框架已有可复用的早期成熟形态
- 生产应用已经足够支撑工程实践总结
- NIST 已正式启动 AI Agent 标准化,但标准仍在制定中
- 基础研究仍在早期
这是一个充满机遇的时刻。无论你是工程师、管理者、研究者还是企业决策者,都可以在这个浪潮中找到自己的位置和贡献。
下一个十年,Harness 工程将如何演进,取决于像你一样的从业者的选择和创新。
附加资源¶
进阶阅读¶
- 论文:GAIA, WebArena, SWE-Bench 原始论文
- 官方文档:Anthropic SDK、Claude API、MCP 规范
- 开源项目:LangChain、LlamaIndex、AutoGen
社区¶
- NIST AI Agent 标准化工作组
- MCP 社区论坛
- Anthropic 开发者社区
- 国内 AI 工程学习社区
建议的学习路径¶
推荐的学习路径和阶段划分如下:
graph LR
A["<b>第一阶段</b><br/>2周"] --> B["<b>第二阶段</b><br/>2周"]
B --> C["<b>第三阶段</b><br/>1周"]
C --> D["<b>第四阶段</b><br/>1周"]
D --> E["<b>第五阶段</b><br/>可选"]
A --> A1["<b>阅读第1-4章</b><br/>掌握基本架构"]
A --> A2["跑通MiniHarness示例"]
A --> A3["理解工具调用机制"]
B --> B1["<b>阅读第5-8章</b><br/>掌握高级特性"]
B --> B2["实现自己的tools"]
B --> B3["评估LLM选择"]
C --> C1["<b>阅读第12章</b><br/>安全防护"]
C --> C2["集成安全模块"]
C --> C3["安全测试"]
D --> D1["<b>阅读第13章</b><br/>评估方法"]
D --> D2["建立评估基线"]
D --> D3["性能基准测试"]
E --> E1["<b>阅读第14章</b><br/>未来展望"]
E --> E2["关注标准演进"]
E --> E3["技术前瞻规划"]
style A fill:#fff9c4
style B fill:#c8e6c9
style C fill:#bbdefb
style D fill:#f8bbd0
style E fill:#e1bee7
感谢阅读《智能体 Harness 工程指南》。现在,该是你用所学去构建下一代应用的时候了。