Agent Harness 不只是 Tool Loop

**「能调工具、能循环」只是 harness 的骨架,不是 harness。** 一个 Agent 服务如果只是「固定系统提示词 + 硬编码工具 + 框架提供的 Tool Loop」,那它只是 MVP —— 缺的是记忆、技能注册表、上下文工程和运行生命周期。

最小骨架 vs 完整 harness

只有骨架(MVP)harness 该有的
固定 Markdown 系统提示词提示词分层与版本管理
工具硬编码在文件里Tool Registry + 参数校验
Skill 是两个枚举(在提示词后拼一段)可注册、可配置、用户可自定义的 Skill 系统
短期「记忆」= 把最近 N 条原始消息重塞给模型Token 预算、摘要压缩、重要信息保留、上下文淘汰
无长期记忆:偏好 / 事实 / 习惯 / 人物的抽取、召回、更新、遗忘
无运行状态、步骤日志、上下文快照、暂停恢复、重试策略
无定时任务能反过来触发某个 Skill

判据:别把「用了别人的 loop」当成「有自己的 harness」

调用 ToolLoopAgent 之类的现成 loop,说明循环本身不用自己写;但 harness 的其余部分不会因此出现。判断一个 Agent 服务成熟度时,逐项问上面右列 —— 缺的那一列才是真正的工作量。

另:写入类工具的安全边界(提案 → 用户确认 → 执行)是骨架里做对了的部分,应该保留而不是重写(见 阻塞式工具与提案确认)。

附:现成 loop 长什么样(以 Vercel AI SDK 的 ToolLoopAgent 为例)

它的定义就是 Agent = LLM + Tools + Loop:

用户消息 → 调模型 → 模型要调 tool?
                     是 → 执行 tool → 结果塞回消息 → 再调模型 …
                     否 → 输出最终 text,结束

停止条件(源码注释):模型不再返回 tool-calls(正常结束)/tool 没有 execute(要外部接)/tool 需要 approval(needsApproval)/命中 stopWhen(默认约 20 步)。

它是一个 SDK 自带的 tool-calling 状态机,不是自研类、也不是 LangGraph / Mastra;业务库、鉴权、propose-confirm 都在它外面。旧名叫 Experimental_Agent,现已正名。

→ 这正是本节的主题:把「循环」外包出去,剩下的 harness(记忆、技能注册表、上下文工程、运行生命周期)一件都不会因此出现。

相关

  • Agent编排层薄自建优先于重型框架 —— 哪些底层该复用、哪些边界必须自建
  • 阻塞式工具与提案确认 —— 写工具如何暂停等确认
  • 上下文成本由基础上下文和会话数决定 —— 短期记忆为什么不能靠「塞最近 N 条」
  • 远程Agent控制要定义执行协议与状态模型 —— 运行状态与生命周期
  • Agent会话要按树保存而不是消息列表 —— 会话与运行生命周期是 harness 的一部分
  • 网页读取工具要受控而不是直连任意URL —— 工具是 runtime 注册的受控能力,不是「模型能访问 URL」
  • Agent harness 要隔离复现可收尾 —— 同名不同义:那条指「调试用 harness」,本条指「产品里的 Agent 运行骨架」