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

作者：Tw93 (@HiTw93) · 发布：2026-03-21

基本信息

核心观点

Agent 工程的核心不是模型够不够强，而是 Harness 够不够硬、上下文组织够不够好、工具描述够不够准。

关键结论

1. 更贵的模型提升有限 — Harness 和验证测试质量对成功率影响更大
2. 工具描述是第一调试点 — 多数工具选择错误出在描述不准确
3. 评测系统问题比 Agent 问题更难发现 — 反复调 Agent 代码效果未必明显

内容结构

1. Agent Loop（核心循环）

• 感知→决策→行动→反馈，不到 20 行代码
• 主循环非常稳定，新能力叠加在外部而非改动内部
• Workflow vs Agent：控制权在代码是 Workflow，在 LLM 是 Agent

2. 五种控制流模式

• Prompt Chaining：顺序步骤
• Routing：分类分发
• Parallelization：并行/投票
• Orchestrator-Workers：编排器-工作者
• Evaluator-Optimizer：评估器-优化器

3. Harness（测试验证基础设施）

四要素：验收基线、执行边界、反馈信号、回退手段

• 任务分类：目标明确+可自动验证 = Agent 最佳区域
• Harness 的目标是把任务推向右上角

4. 上下文工程

分层管理：

• 常驻层：身份/约定/禁止项，短硬稳定，保护缓存命中
• 按需加载：Skills，描述符常驻，完整内容触发注入
• 运行时注入：时间、渠道、用户偏好
• 记忆层：跨会话经验，需要时才读
• 系统层：Hooks/代码规则，不进上下文

5. Prompt Caching

• 精确前缀匹配，稳定性是关键
• 常驻层越稳定，命中率越高，边际成本越低
• 稳定的大系统提示 < 频繁变动的小提示 实际成本更低

6. Skills 设计

• 系统提示只保留索引，完整知识按需加载
• 必须写反例：无反例准确率 53%，有反例 85%，响应时间降 18%
• 描述要像路由条件：Use when / Don't use when + 反例

实战数据

• 3 个工程师 5 个月写了百万行代码，近 1500 个 PR，传统速度 10 倍
• 约束编码化 > 文档化（Linter > 文档规范）
• Agent 端到端自主：验证→修复→开 PR→处理 Review→合并

相关文件

• 架构图：Agent工程实践架构图.canvas
• 深度技术分析：Agent工程实践深度技术分析.html