1. 核心定义
Harness，就是除了 LLM 本身之外，让 Agent 真正能干活的一切基础设施。
简洁定义：Agent = LLM + Harness
Harness 是除 LLM 本体外，支撑 Agent 完成生产任务的全部基础设施与工程体系的总和。它并非优化 Prompt 或升级模型，而是通过构建模型运行的环境、机制、规则与边界，实现 AI 智能的工程化落地。
如果说 LLM 是 Agent 的"大脑"，那么 Harness 就是 Agent 的"身体"和"工作环境"。一个没有 Harness 的 LLM，只是一个能聊天的模型；一个拥有完整 Harness 的 LLM，才能真正读取文件、调用 API、操作数据库、执行代码——成为真正能"干活"的 Agent。
2. Harness 的体系组成
从工程角度看，Harness 主要包含以下几个层次：
2.1 运行时环境
Agent 运行的基础层，包括执行上下文、沙箱机制、资源管理。运行时决定了 Agent 的"生存空间"——它能访问哪些资源、能执行什么操作、能存活多长时间。常见的实现包括 Docker 容器、虚拟机沙箱、以及云函数等 Serverless 环境。
2.2 工具链
工具是 Agent 与外部世界交互的手段。包括文件读写、网络请求、数据库查询、Shell 命令执行等。MCP（Model Context Protocol）正在成为连接 LLM 与工具的标准协议，而 Function Calling 则是各家模型厂商提供的基础能力。
2.3 记忆系统
Agent 需要"记住"上下文——对话历史、用户偏好、执行状态。记忆系统分为短期记忆（当前会话上下文）、工作记忆（任务执行中间状态）和长期记忆（持久化的知识与偏好）。向量数据库（如 Pinecone、Milvus）和传统数据库的结合是实现记忆系统的常见方案。
2.4 安全边界
赋予 Agent 执行能力的同时，必须建立安全边界。包括权限控制（Agent 能调哪些工具、能访问哪些资源）、输入输出过滤（防止注入攻击和敏感信息泄露）、审计日志（记录 Agent 的所有行为）。安全不是可选的附加功能，而是 Harness 的内建属性。
2.5 交互协议
Agent 与人、Agent 与 Agent、Agent 与系统之间的通信方式。包括消息格式、任务分发、状态同步。良好的交互协议使得 Agent 能够被组合、编排，形成更复杂的 Agent 网络。
3. 为什么 Harness 是 Agent 落地的关键
很多人认为构建 Agent 的核心是选一个好模型、写好 Prompt。但实际工程化中，以下问题才是真正的瓶颈：
- 可靠性：LLM 输出不稳定，Harness 通过重试、校验、降级策略来保证整体任务的可靠执行。
- 可观测性：Agent 执行链路长、环节多，需要完善的日志、追踪和监控。
- 成本控制：LLM 调用有成本，Harness 通过缓存、智能路由、请求合并来降低成本。
- 可扩展性：从单个 Agent 到多 Agent 协作，Harness 提供编排和通信的基础设施。
一句话概括：LLM 决定了 Agent 的上限，Harness 决定了 Agent 的下限。没有扎实的 Harness 工程，再好的模型也只能停留在 Demo 阶段。
4. 学习小结
理解 Harness 的概念，意味着从"如何让模型回答得更好"的视角，转向"如何让模型真正完成工作"的视角。这是一个从 Prompt Engineering 到 Harness Engineering 的转变——前者关注单次对话的质量，后者关注持续交付的可靠性。
后续学习中，我计划分别深入运行时环境、工具链、记忆系统这几个方向，结合实际项目，逐步搭建一套真正可用的 Agent 基础设施。