前言这两年大家聊 AI 系统时最容易被反复提起的一个词就是Agent好像只要系统会调用工具、会拆任务、会自己往下执行它就已经是一个“高级 AI Agent”了。但如果你真的开始做这类系统很快就会发现一个问题模型会思考不代表系统能稳定执行模型会调用工具不代表工具调用是安全的模型能往下做几步不代表整条链路可控、可审计、可复现这时候你会意识到真正把一个 Agent 系统跑起来的从来不只是 Agent 本身。在 Agent 外面通常还包着一层更底层、但经常被忽略的东西Harness很多人第一次听到这个词会觉得它像个“包装器”或者“运行壳”。但从工程角度看它远不只是一个外壳。如果说 Agent 负责“怎么想、下一步做什么”那么 Harness 负责的其实是能不能做怎么做在什么边界里做做错了怎么办整个过程如何被观测、限制和治理也就是说Agent 决定系统有没有“智能感”Harness 决定系统有没有“工程性”。所以真正成熟的 AI 系统几乎从来不是单独一个 Agent而是Agent Harness一、为什么很多人会把 Agent 和 Harness 搞混1. 因为在 Demo 里它们经常被包成一个东西很多人第一次接触 Agent看到的都是类似这样的演示用户输入一个任务模型开始分析模型调用工具模型读文件、写代码、查网页模型继续推进任务最后给出结果从表面看好像整个系统就是“Agent 在工作”。但实际上这里面往往已经隐含了一大堆非 Agent 的能力工具接口是谁提供的工具参数是谁校验的哪些目录能读写是谁限制的网络能不能访问是谁控制的高风险命令是否需要确认是谁决定的整个执行过程的日志是谁记录的失败重试和超时中断是谁处理的这些东西很多并不属于 Agent 本身而是属于它外面的执行与控制层。只是 Demo 里通常不会把这层单独讲出来于是很多人会误以为“会调工具的模型” “完整 Agent 系统”其实中间还差了很重要的一层就是 Harness。2. 因为 Agent 更显眼Harness 更像“幕后系统”从直觉上讲人们更容易注意到“会思考、会调用工具、会执行任务”的部分。因为那一层看起来最像“智能”。而 Harness 做的事往往更偏工程基础设施上下文拼装工具暴露权限控制沙箱隔离状态管理预算限制日志和 trace中断与审批回放与审计这些能力虽然不如 Agent 那么“炫”但系统一旦要进入真实环境它们的重要性反而会急剧上升。所以才会出现一个很典型的误区很多人以为 Agent 是主角Harness 只是配角。但在真正可落地的系统里Harness 往往决定了这个 Agent 能不能真正工作。二、什么是 Agent1. Agent 的本质是“决策层”如果一定要用一句话概括 Agent它更接近的是负责决定下一步做什么的那一层。它的核心任务通常包括理解用户目标拆分任务判断当前状态选择下一步动作决定是否调用工具根据反馈调整策略在多步执行中持续推进任务换句话说Agent 不只是“生成一段回答”它更像是在做一个持续循环看目标看当前状态想下一步执行动作读取反馈再决定下一步这个循环就是很多 Agent 系统最核心的“智能感”来源。2. Agent 最像什么最像“大脑”或“驾驶员”一个比较直观的比喻是Agent 像大脑或者说Agent 像驾驶员它决定方向、判断局势、规划动作。比如用户说“帮我定位这个线上回归 bug并修掉它。”一个 Agent 可能会这样想先看报错信息再查最近提交记录再找相关模块先读配置文件如果是测试失败先跑测试如果定位到代码改动再生成修复方案这些“先做什么、后做什么、要不要换路径”的事情基本都属于 Agent 的范畴。所以可以说Agent 负责的是意图到动作之间的决策。3. 但 Agent 本身并不等于整个系统这点非常关键。Agent 可以知道“应该去读文件”但它本身未必负责这些问题读哪个目录被允许能不能读系统敏感文件读文件这个动作的超时时间是多少失败后是否重试这次读文件有没有被记录下来如果这个动作危险是否需要人工确认也就是说Agent 可以提出动作意图但动作如何被允许、被限制、被执行往往不是 Agent 单独决定的。这就引出了另一半Harness三、什么是 Harness1. Harness 的本质是“执行控制层”如果说 Agent 是“做决策的那层”那么 Harness 更像是让这些决策变成可执行、可约束、可观测系统行为的那一层。它不是负责“替模型思考”而是负责把模型的思考结果接进真实世界。所以 Harness 干的通常是这些事给 Agent 提供工具给 Agent 注入上下文限制 Agent 的操作边界管理状态和会话控制权限、预算和超时记录日志和执行轨迹处理失败、中断、审批和回滚换句话说Harness 不是智能层而是运行层。2. Harness 最像什么最像“操作系统”或“驾驶舱”如果继续沿用刚才的类比Agent 像驾驶员Harness 更像车辆 仪表盘 限速器 安全带 护栏 交通规则驾驶员决定往哪走但车能不能启动时速能不能超过限制能不能开进某条路哪些操作会触发警报发生风险能不能紧急制动这些并不是驾驶员一个人说了算而是由整套运行和安全机制共同决定。这就是 Harness 的角色。它不是“替你开车”而是让开车这件事变得可控、可观察、可治理。3. 一个成熟的 Harness通常至少承担这几类职责1上下文装配Harness 负责决定给 Agent 哪些系统提示注入哪些历史消息暴露哪些记忆提供哪些文件或任务状态当前轮次到底看到什么上下文也就是说Agent 并不是“直接面对世界”而是先通过 Harness 看到一个被组织过的环境。2工具与环境暴露Harness 负责把工具接给 Agent例如文件系统shell浏览器数据库HTTP内部 API搜索与检索工具同时也负责定义工具长什么样输入参数怎么校验返回结果如何格式化哪些工具可用哪些不可用3权限与安全边界这是 Harness 特别核心的一部分。例如它需要决定哪些目录可读可写是否允许联网是否允许执行高危命令是否能访问生产环境是否需要审批才能继续是否必须在沙箱里执行很多团队以为“安全”是 Agent 自己学会谨慎但真正的系统安全通常是 Harness 提供的。4状态、预算与生命周期管理Harness 还要管理很多运行时问题比如这次任务持续多久token / 成本预算是多少哪些中间状态需要保存哪些结果需要回传给下一轮任务失败后是否重试会话什么时候结束这些也往往不是 Agent 本身最擅长处理的而更适合放在外部运行层。5观测、审计与中断一个真正能上线的系统必须知道Agent 做了什么为什么做这一步调了哪些工具哪一步失败了哪一步超时了哪一步被人类中断了最终结果是怎么来的这些能力很大程度上也属于 Harness。可以说没有观测能力的 Agent更像演示有观测能力的 Agent才更像系统。四、Agent 和 Harness 到底怎么分工1. 一个最简洁的区分方式如果要做一个非常直接的划分可以这样理解Agent 负责回答现在目标是什么我下一步应该做什么要不要调用工具结果看起来对不对要不要换个策略Harness 负责回答这一步能不能做这个工具怎么调这个动作权限够不够这一步是否要审批这次执行是否超时这个结果怎么记录和传递所以两者的差别可以浓缩成一句话Agent 决定“做什么”Harness 决定“怎么安全、稳定、可控地做”。2. 一个 coding agent 场景会更容易看清楚假设用户说“帮我修复这个测试失败问题并补上缺失测试。”这时Agent 可能负责理解用户目标判断需要先跑测试读取测试输出猜测可能相关文件决定先修实现还是先修测试生成修改计划根据反馈继续推进而 Harness 可能负责提供 run_test、read_file、edit_file 等工具限制只能操作当前工作区禁止访问系统敏感目录限制网络权限对危险写操作做审批记录每一步命令和文件改动控制执行超时保存 patch 和日志在用户中断时安全停机你会发现Agent 很重要但它只是“决策者”真正让整个过程变成一个可运行系统的是外面的 Harness。3. 没有 HarnessAgent 往往只能停留在“会想”这是很多人容易忽略的一点。如果一个系统只有 Agent没有 Harness它通常会出现两种情况第一种它只能“建议”不能真正“执行”也就是它会说你可以去读这个文件你应该跑这个命令你可能要改这里你最好再查一下日志听起来像个顾问但不是执行体。第二种它能执行但行为不可控也就是它可以真的去做事但没权限边界没审批机制没日志没中断没预算没回滚没沙箱这种系统短期可能很惊艳长期通常很危险。所以真正可用的系统不是“只有 Agent”而是Agent 必须运行在一个设计良好的 Harness 之上。五、为什么说 Harness 往往比 Agent 更决定系统能不能落地1. 因为模型能力越来越强但系统治理不会自动出现未来更强的模型会越来越多Agent 的基础决策能力也会逐渐变强。但这并不意味着系统会自动变得可上线。因为这些能力不会自动从模型里长出来沙箱隔离权限控制工具网关日志追踪成本治理超时中断人类审批审计与回放这些东西本质上更像基础设施问题而不是模型问题。也就是说模型进步会提升 Agent 的大脑但 Harness 决定这个大脑能不能接进真实世界。2. 因为很多所谓“Agent 失控”本质上是 Harness 设计不完善现实里很多问题看起来像 Agent 不够聪明其实更接近 Harness 没设计好。例如任务越做越偏可能是状态管理差工具乱调可能是工具暴露太宽改动越界可能是权限边界太弱成本爆炸可能是预算控制缺失出错无法追踪可能是日志与 trace 不完整风险动作没人拦可能是审批链没接所以很多工程问题最后并不只是“换更强模型”能解决的。真正该补的往往是Harness 这层系统能力3. 因为真正的产品护城河经常不在 Agent而在 Harness从产品视角看很多团队会把精力大量投入到prompt 怎么写agent loop 怎么设计tool use 怎么提示planner 怎么做这些当然都重要。但如果只看 Agent 层你会发现大家很容易越来越趋同。真正能拉开差距的地方很多时候反而在 Harness你的权限模型设计得怎么样你的工具治理做得怎么样你的沙箱和工作区隔离做得怎么样你的观测、评估、审计是否完整你的中断与人类协作机制是否顺畅这些地方看起来不如“Agent 很聪明”那么显眼但它们往往更决定一个系统能不能长期跑、敢不敢上线、能不能进企业流程。六、那什么才叫“好的 Agent Harness 设计”1. Agent 保持专注负责决策不要背太多系统责任一个常见错误是把太多运行时责任都塞给 Agent 本身。比如让 Agent 自己负责记所有状态自己判断权限自己决定是否危险自己做审计记录自己约束成本这样做的问题是prompt 会越来越重规则会越来越乱模型负担越来越大系统行为越来越不稳定更合理的方式通常是让 Agent 专注在决策把权限、治理、观测、边界这些系统职责下沉到 Harness。2. Harness 要最小暴露而不是默认全开一个好的 Harness通常不是“把所有工具都给 Agent再告诉它谨慎使用”。而是默认只暴露必要工具默认只给最小权限默认在沙箱环境中执行默认高风险动作要确认默认可观测、可审计、可中断这会带来一个很重要的效果就算 Agent 偶尔判断错了出错半径也会比较小。3. 两者之间要有清晰接口而不是互相污染成熟系统里Agent 和 Harness 之间最好有清晰边界Agent 通过定义良好的工具接口提需求Harness 通过统一规则执行动作中间状态通过结构化方式传递风险策略由 Harness 统一托管Agent 不直接“裸奔式”接触外部环境这样做的好处是更容易调试更容易替换模型更容易替换工具更容易做权限治理更容易做版本迭代换句话说Agent 和 Harness 的关系不应该是混成一团而应该像“决策层”和“运行层”一样清晰协作。总结很多人讨论 AI 系统时最容易把注意力集中在 Agent 上它会不会拆任务它会不会用工具它会不会自主执行它是不是越来越像数字员工这些当然都重要。但如果只盯着 Agent你会很容易漏掉真正把系统变成“工程产品”的另一半Harness因为一个系统能不能工作不只是看它会不会想还要看它能不能安全执行能不能被限制边界能不能被观测和审计能不能处理中断、失败和回滚能不能稳定接进真实环境所以从工程角度看Agent 是智能核心Harness 是运行基础设施前者决定“它会不会做事”后者决定“它能不能在真实世界里把事做好”。这也是为什么只谈 Agent 往往是不够的。真正成熟的 AI 系统几乎都不是单独一个 Agent而是Agent Harness 共同构成的执行系统。如果说 Agent 决定的是系统的“思考能力”那么 Harness 决定的就是系统的“落地能力”。而后者往往才是真正把 Demo 变成产品的那一层。一句话结论Agent 负责决定下一步做什么Harness 负责让这一步可执行、可约束、可观测、可治理。
为什么只谈 Agent 还不够？——一文讲清楚 Agent 和 Harness 到底分别是什么
发布时间：2026/6/10 22:48:45
前言这两年大家聊 AI 系统时最容易被反复提起的一个词就是Agent好像只要系统会调用工具、会拆任务、会自己往下执行它就已经是一个“高级 AI Agent”了。但如果你真的开始做这类系统很快就会发现一个问题模型会思考不代表系统能稳定执行模型会调用工具不代表工具调用是安全的模型能往下做几步不代表整条链路可控、可审计、可复现这时候你会意识到真正把一个 Agent 系统跑起来的从来不只是 Agent 本身。在 Agent 外面通常还包着一层更底层、但经常被忽略的东西Harness很多人第一次听到这个词会觉得它像个“包装器”或者“运行壳”。但从工程角度看它远不只是一个外壳。如果说 Agent 负责“怎么想、下一步做什么”那么 Harness 负责的其实是能不能做怎么做在什么边界里做做错了怎么办整个过程如何被观测、限制和治理也就是说Agent 决定系统有没有“智能感”Harness 决定系统有没有“工程性”。所以真正成熟的 AI 系统几乎从来不是单独一个 Agent而是Agent Harness一、为什么很多人会把 Agent 和 Harness 搞混1. 因为在 Demo 里它们经常被包成一个东西很多人第一次接触 Agent看到的都是类似这样的演示用户输入一个任务模型开始分析模型调用工具模型读文件、写代码、查网页模型继续推进任务最后给出结果从表面看好像整个系统就是“Agent 在工作”。但实际上这里面往往已经隐含了一大堆非 Agent 的能力工具接口是谁提供的工具参数是谁校验的哪些目录能读写是谁限制的网络能不能访问是谁控制的高风险命令是否需要确认是谁决定的整个执行过程的日志是谁记录的失败重试和超时中断是谁处理的这些东西很多并不属于 Agent 本身而是属于它外面的执行与控制层。只是 Demo 里通常不会把这层单独讲出来于是很多人会误以为“会调工具的模型” “完整 Agent 系统”其实中间还差了很重要的一层就是 Harness。2. 因为 Agent 更显眼Harness 更像“幕后系统”从直觉上讲人们更容易注意到“会思考、会调用工具、会执行任务”的部分。因为那一层看起来最像“智能”。而 Harness 做的事往往更偏工程基础设施上下文拼装工具暴露权限控制沙箱隔离状态管理预算限制日志和 trace中断与审批回放与审计这些能力虽然不如 Agent 那么“炫”但系统一旦要进入真实环境它们的重要性反而会急剧上升。所以才会出现一个很典型的误区很多人以为 Agent 是主角Harness 只是配角。但在真正可落地的系统里Harness 往往决定了这个 Agent 能不能真正工作。二、什么是 Agent1. Agent 的本质是“决策层”如果一定要用一句话概括 Agent它更接近的是负责决定下一步做什么的那一层。它的核心任务通常包括理解用户目标拆分任务判断当前状态选择下一步动作决定是否调用工具根据反馈调整策略在多步执行中持续推进任务换句话说Agent 不只是“生成一段回答”它更像是在做一个持续循环看目标看当前状态想下一步执行动作读取反馈再决定下一步这个循环就是很多 Agent 系统最核心的“智能感”来源。2. Agent 最像什么最像“大脑”或“驾驶员”一个比较直观的比喻是Agent 像大脑或者说Agent 像驾驶员它决定方向、判断局势、规划动作。比如用户说“帮我定位这个线上回归 bug并修掉它。”一个 Agent 可能会这样想先看报错信息再查最近提交记录再找相关模块先读配置文件如果是测试失败先跑测试如果定位到代码改动再生成修复方案这些“先做什么、后做什么、要不要换路径”的事情基本都属于 Agent 的范畴。所以可以说Agent 负责的是意图到动作之间的决策。3. 但 Agent 本身并不等于整个系统这点非常关键。Agent 可以知道“应该去读文件”但它本身未必负责这些问题读哪个目录被允许能不能读系统敏感文件读文件这个动作的超时时间是多少失败后是否重试这次读文件有没有被记录下来如果这个动作危险是否需要人工确认也就是说Agent 可以提出动作意图但动作如何被允许、被限制、被执行往往不是 Agent 单独决定的。这就引出了另一半Harness三、什么是 Harness1. Harness 的本质是“执行控制层”如果说 Agent 是“做决策的那层”那么 Harness 更像是让这些决策变成可执行、可约束、可观测系统行为的那一层。它不是负责“替模型思考”而是负责把模型的思考结果接进真实世界。所以 Harness 干的通常是这些事给 Agent 提供工具给 Agent 注入上下文限制 Agent 的操作边界管理状态和会话控制权限、预算和超时记录日志和执行轨迹处理失败、中断、审批和回滚换句话说Harness 不是智能层而是运行层。2. Harness 最像什么最像“操作系统”或“驾驶舱”如果继续沿用刚才的类比Agent 像驾驶员Harness 更像车辆 仪表盘 限速器 安全带 护栏 交通规则驾驶员决定往哪走但车能不能启动时速能不能超过限制能不能开进某条路哪些操作会触发警报发生风险能不能紧急制动这些并不是驾驶员一个人说了算而是由整套运行和安全机制共同决定。这就是 Harness 的角色。它不是“替你开车”而是让开车这件事变得可控、可观察、可治理。3. 一个成熟的 Harness通常至少承担这几类职责1上下文装配Harness 负责决定给 Agent 哪些系统提示注入哪些历史消息暴露哪些记忆提供哪些文件或任务状态当前轮次到底看到什么上下文也就是说Agent 并不是“直接面对世界”而是先通过 Harness 看到一个被组织过的环境。2工具与环境暴露Harness 负责把工具接给 Agent例如文件系统shell浏览器数据库HTTP内部 API搜索与检索工具同时也负责定义工具长什么样输入参数怎么校验返回结果如何格式化哪些工具可用哪些不可用3权限与安全边界这是 Harness 特别核心的一部分。例如它需要决定哪些目录可读可写是否允许联网是否允许执行高危命令是否能访问生产环境是否需要审批才能继续是否必须在沙箱里执行很多团队以为“安全”是 Agent 自己学会谨慎但真正的系统安全通常是 Harness 提供的。4状态、预算与生命周期管理Harness 还要管理很多运行时问题比如这次任务持续多久token / 成本预算是多少哪些中间状态需要保存哪些结果需要回传给下一轮任务失败后是否重试会话什么时候结束这些也往往不是 Agent 本身最擅长处理的而更适合放在外部运行层。5观测、审计与中断一个真正能上线的系统必须知道Agent 做了什么为什么做这一步调了哪些工具哪一步失败了哪一步超时了哪一步被人类中断了最终结果是怎么来的这些能力很大程度上也属于 Harness。可以说没有观测能力的 Agent更像演示有观测能力的 Agent才更像系统。四、Agent 和 Harness 到底怎么分工1. 一个最简洁的区分方式如果要做一个非常直接的划分可以这样理解Agent 负责回答现在目标是什么我下一步应该做什么要不要调用工具结果看起来对不对要不要换个策略Harness 负责回答这一步能不能做这个工具怎么调这个动作权限够不够这一步是否要审批这次执行是否超时这个结果怎么记录和传递所以两者的差别可以浓缩成一句话Agent 决定“做什么”Harness 决定“怎么安全、稳定、可控地做”。2. 一个 coding agent 场景会更容易看清楚假设用户说“帮我修复这个测试失败问题并补上缺失测试。”这时Agent 可能负责理解用户目标判断需要先跑测试读取测试输出猜测可能相关文件决定先修实现还是先修测试生成修改计划根据反馈继续推进而 Harness 可能负责提供 run_test、read_file、edit_file 等工具限制只能操作当前工作区禁止访问系统敏感目录限制网络权限对危险写操作做审批记录每一步命令和文件改动控制执行超时保存 patch 和日志在用户中断时安全停机你会发现Agent 很重要但它只是“决策者”真正让整个过程变成一个可运行系统的是外面的 Harness。3. 没有 HarnessAgent 往往只能停留在“会想”这是很多人容易忽略的一点。如果一个系统只有 Agent没有 Harness它通常会出现两种情况第一种它只能“建议”不能真正“执行”也就是它会说你可以去读这个文件你应该跑这个命令你可能要改这里你最好再查一下日志听起来像个顾问但不是执行体。第二种它能执行但行为不可控也就是它可以真的去做事但没权限边界没审批机制没日志没中断没预算没回滚没沙箱这种系统短期可能很惊艳长期通常很危险。所以真正可用的系统不是“只有 Agent”而是Agent 必须运行在一个设计良好的 Harness 之上。五、为什么说 Harness 往往比 Agent 更决定系统能不能落地1. 因为模型能力越来越强但系统治理不会自动出现未来更强的模型会越来越多Agent 的基础决策能力也会逐渐变强。但这并不意味着系统会自动变得可上线。因为这些能力不会自动从模型里长出来沙箱隔离权限控制工具网关日志追踪成本治理超时中断人类审批审计与回放这些东西本质上更像基础设施问题而不是模型问题。也就是说模型进步会提升 Agent 的大脑但 Harness 决定这个大脑能不能接进真实世界。2. 因为很多所谓“Agent 失控”本质上是 Harness 设计不完善现实里很多问题看起来像 Agent 不够聪明其实更接近 Harness 没设计好。例如任务越做越偏可能是状态管理差工具乱调可能是工具暴露太宽改动越界可能是权限边界太弱成本爆炸可能是预算控制缺失出错无法追踪可能是日志与 trace 不完整风险动作没人拦可能是审批链没接所以很多工程问题最后并不只是“换更强模型”能解决的。真正该补的往往是Harness 这层系统能力3. 因为真正的产品护城河经常不在 Agent而在 Harness从产品视角看很多团队会把精力大量投入到prompt 怎么写agent loop 怎么设计tool use 怎么提示planner 怎么做这些当然都重要。但如果只看 Agent 层你会发现大家很容易越来越趋同。真正能拉开差距的地方很多时候反而在 Harness你的权限模型设计得怎么样你的工具治理做得怎么样你的沙箱和工作区隔离做得怎么样你的观测、评估、审计是否完整你的中断与人类协作机制是否顺畅这些地方看起来不如“Agent 很聪明”那么显眼但它们往往更决定一个系统能不能长期跑、敢不敢上线、能不能进企业流程。六、那什么才叫“好的 Agent Harness 设计”1. Agent 保持专注负责决策不要背太多系统责任一个常见错误是把太多运行时责任都塞给 Agent 本身。比如让 Agent 自己负责记所有状态自己判断权限自己决定是否危险自己做审计记录自己约束成本这样做的问题是prompt 会越来越重规则会越来越乱模型负担越来越大系统行为越来越不稳定更合理的方式通常是让 Agent 专注在决策把权限、治理、观测、边界这些系统职责下沉到 Harness。2. Harness 要最小暴露而不是默认全开一个好的 Harness通常不是“把所有工具都给 Agent再告诉它谨慎使用”。而是默认只暴露必要工具默认只给最小权限默认在沙箱环境中执行默认高风险动作要确认默认可观测、可审计、可中断这会带来一个很重要的效果就算 Agent 偶尔判断错了出错半径也会比较小。3. 两者之间要有清晰接口而不是互相污染成熟系统里Agent 和 Harness 之间最好有清晰边界Agent 通过定义良好的工具接口提需求Harness 通过统一规则执行动作中间状态通过结构化方式传递风险策略由 Harness 统一托管Agent 不直接“裸奔式”接触外部环境这样做的好处是更容易调试更容易替换模型更容易替换工具更容易做权限治理更容易做版本迭代换句话说Agent 和 Harness 的关系不应该是混成一团而应该像“决策层”和“运行层”一样清晰协作。总结很多人讨论 AI 系统时最容易把注意力集中在 Agent 上它会不会拆任务它会不会用工具它会不会自主执行它是不是越来越像数字员工这些当然都重要。但如果只盯着 Agent你会很容易漏掉真正把系统变成“工程产品”的另一半Harness因为一个系统能不能工作不只是看它会不会想还要看它能不能安全执行能不能被限制边界能不能被观测和审计能不能处理中断、失败和回滚能不能稳定接进真实环境所以从工程角度看Agent 是智能核心Harness 是运行基础设施前者决定“它会不会做事”后者决定“它能不能在真实世界里把事做好”。这也是为什么只谈 Agent 往往是不够的。真正成熟的 AI 系统几乎都不是单独一个 Agent而是Agent Harness 共同构成的执行系统。如果说 Agent 决定的是系统的“思考能力”那么 Harness 决定的就是系统的“落地能力”。而后者往往才是真正把 Demo 变成产品的那一层。一句话结论Agent 负责决定下一步做什么Harness 负责让这一步可执行、可约束、可观测、可治理。
