你不知道的 Agent：原理、架构与工程实践

📌 一句话摘要

本文系统性地阐述了 Agent 架构中影响工程效果的核心要素，包括控制流、上下文工程、工具设计、记忆系统、多 Agent 组织、评测与追踪，并通过 OpenClaw 案例串联实践原则。

📝 详细摘要

文章基于作者的技术实践与独立思考，深入剖析了 Agent 系统的工程实现细节。核心观点包括：Agent Loop 的核心逻辑稳定，新能力通过扩展工具集、调整系统提示和状态外化接入；Harness（测试与约束基础设施）对系统稳定性的影响常大于模型本身；上下文需按常驻层、按需加载、运行时注入、记忆层和系统层分层管理，避免噪声稀释关键信号；工具设计应遵循 ACI 原则，以 Agent 目标而非 API 操作为粒度，并提供结构化错误和示例；记忆系统需区分工作记忆、程序性记忆、情景记忆和语义记忆，通过 MEMORY.md 和 Skills 协作实现跨会话一致性；多 Agent 组织需先建立结构化通信协议、任务图和隔离边界，再谈协作与并行；评测体系应从 20-50 个真实失败案例起步，优先使用代码评分器，并先排查评测系统本身的问题再修改 Agent。文章最后通过 OpenClaw 案例展示了这些原则的落地实现。

💡 主要观点

- Agent 核心循环稳定，新能力通过扩展工具集、调整系统提示和状态外化接入。 Agent Loop 的核心逻辑（感知-决策-行动-反馈）抽象后不到 20 行代码，新增能力不应修改循环内部，而是通过扩展工具集、调整系统提示结构、将状态外化到文件或数据库来实现。

Harness（测试与约束基础设施）对系统稳定性的影响常大于模型本身。 Harness 包括验收基线、执行边界、反馈信号和回退手段。在代码编写等高可验证任务中，决定系统能否稳定运行的往往是这些外围工程条件，而非模型能力。

上下文需按信息使用频率和稳定性分层管理，避免 Context Rot。 上下文应分为常驻层、按需加载、运行时注入、记忆层和系统层。确定性逻辑应交给外部系统处理，不进入上下文。Skills 按需加载、Prompt Caching 等策略可有效降低上下文成本和提升稳定性。

工具设计应遵循 ACI 原则，以 Agent 目标为粒度，并提供结构化错误和示例。 工具应对应 Agent 要完成的目标而非底层 API 操作，描述应说明何时用、何时不用，返回与下一步决策直接相关的字段，错误应结构化并包含修正建议。调试 Agent 时应优先检查工具定义。

评测体系应从 20-50 个真实失败案例起步，优先使用代码评分器，并先排查评测系统问题。 评测的核心是测试用例、评分标准和自动验证。有明确正确答案的任务优先使用代码评分器。看到评测分数下降时，应先检查运行环境、评分器 bug 等基础设施问题，再修改 Agent。

💬 文章金句

- 模型负责推理，外部系统负责状态和边界，一旦这个分工确定下来，核心循环逻辑就很少需要频繁调整了。

• Harness 要做的就是把任务推进右上角，让对错有机器可以执行的判断标准，而不是靠人盯。
• 调试 Agent 时应先检查工具定义，大多数工具选择错误的原因出在描述不准确，不在模型能力。
• 评测出问题了，你拿到的是一个失真的信号，基于它去改 Agent，改的方向可能从一开始就是错的。
• 先有可持久化任务图，再引入有身份的队友，再引入结构化通信协议，最后再加交叉验证或外部反馈。

📊 文章信息

AI 初评：92

来源：阿里云开发者

作者：阿里云开发者

分类：人工智能

语言：中文

阅读时间：69 分钟

字数：17167

标签： Agent 架构, 上下文工程, 工具设计, 记忆系统, 多 Agent 协作

阅读完整文章