Hidden Technical Debt of AI Systems: Agent Harness¶
Ch04.487 Hidden Technical Debt of AI Systems: Agent Harness¶
📊 Level ⭐⭐ | 3.4KB |
entities/hidden-technical-debt-agent-harness.md
Hidden Technical Debt of AI Systems: Agent Harness¶
Background：本文基于 leehanchung 2026-05-08 发表的深度技术分析，系统梳理了 AI Agent 系统中"Harness 层"的技术债务问题。文章以 Google 经典论文《Hidden Technical Debt in Machine Learning Systems》为类比，指出 Agent 系统中真正的工程复杂度不在模型本身，而在围绕模型的 Harness 层——system prompts、tool wrappers、planner-executor loops、retry policies、context compaction 策略等。
核心论点¶
Agent 系统的 Harness 层（系统提示词、工具包装器、规划-执行循环、重试策略、上下文压缩策略、工具调用白名单、停止判断器、降级方案）构成了真正的技术债务来源。即使使用 n8n 等低代码工具绘制工作流，本质上仍是 Harness 工程。
Harness 层的五个技术债务维度¶
1. System Prompt 膨胀¶
- 系统提示词持续增长，团队不断添加新规则和边界条件
- 每次新增工具或功能都需要更新 prompt，导致维护成本指数增长
- Prompt 之间存在隐式依赖和冲突，难以测试和验证
2. Tool Wrapper 脆弱性¶
- 工具包装器将外部 API 的复杂性封装为 LLM 可调用的接口
- API 变更、认证过期、速率限制等外部因素导致 wrapper 频繁失效
- 每个 wrapper 都是潜在的故障点，需要独立的错误处理和重试逻辑
3. Planner-Executor 循环的隐式状态¶
- 规划器和执行器之间的状态传递依赖隐式约定
- 上下文窗口限制导致历史信息丢失，规划器可能重复已失败的操作
- 缺乏显式的状态机设计，使得调试和可观测性极差
4. Context Compaction 策略¶
- 长对话需要压缩历史上下文以适应模型窗口
- 压缩策略（摘要、截断、滑动窗口）各有权衡，且与具体任务强相关
- 错误的压缩可能导致关键信息丢失，影响后续推理质量
5. Model Capability Evolution 的适配成本¶
- 模型能力快速演进，Harness 层的假设可能过时
- 为旧模型设计的 guardrails 可能限制新模型的能力发挥
- 团队需要持续评估和调整 Harness 层的设计
与现有实体的差异化¶
本文从技术债务视角审视 Agent Harness，与现有 harness-engineering-systematic-framework（通用理论框架）和 agent-harness-context-management-working-set（上下文管理专项）形成互补： - 现有实体侧重如何构建 Harness - 本文侧重Harness 的维护成本和债务累积
实践启示¶
- Harness 层应作为独立的工程对象管理，而非 prompt + code 的随意组合
- 需要 Harness 层的测试框架，类似于软件工程中的集成测试
- 模型升级时应评估 Harness 兼容性，而非只关注模型本身的 benchmark
- 可观测性是 Harness 工程的基础——没有 trace 和 log，调试 harness 问题如同大海捞针
参考¶
→ 原文存档 → Harness Engineering 框架