最近在一次内部技术评审会上有人把传统操作系统的系统调用栈和大模型应用的架构图叠在同一页 PPT 里底部一行字写着“智能体是新的内核”。AI Agent Harness Engineering 这个词也是在那次会上被反复抛出来。会议室里一半人点头另一半人在皱眉。我属于皱眉的那一半但会后花了一个多月时间把两边架构一层层对账结论慢慢变了这个类比确实粗糙可它指向的方向值得认真对待——如果智能体真的会成为未来计算平台的核心那么决定平台成败的大概率不是模型本身的得分而是包住模型的那一层 Harness 工程体系。这篇文章适合正在做智能体应用、天天跟上下文窗口和工具调用缠斗的工程师也适合准备在公司内部搭 AI 平台、需要判断技术路线的技术管理者。我不打算讨论大模型会不会通向通用人工智能只想聊一件更务实的事把智能体当作“可运行的系统”来工程化到底要拆出哪些子系统哪些坑只有真正做进去的人才碰得到以及“Harness”这个提法是不是真的抓住了要害。1. 从“系统调用”到“意图调用”智能体与操作系统的对账1.1 这个类比为什么会突然流行过去一年智能体从一个演示概念变成了实际业务里的常驻角色。我自己所在团队从最早的“一问一答”式对话机器人做到现在把模型嵌进订单处理、数据质检、设备巡检这些具体流程里。变化最明显的不是模型能力本身而是模型周围的软件形态它开始有工具列表、有记忆库、有任务队列有超时重试甚至还有权限审批流程。这时候你回头看传统操作系统会发现结构上确实存在相似性。操作系统管理的资源是 CPU、内存、磁盘、网络核心抽象是进程、文件、调度、权限而一个智能体平台管理的资源是模型实例、上下文窗口、外部工具、向量检索库核心抽象则是任务、会话、工具调用、知识条目。系统调用是程序与内核的接口工具调用是智能体与外部世界的接口。这种对应关系一列出来很多人自然会喊出“智能体即操作系统”的口号。1.2 一张对照表以及对照不上的地方我做过一张逐项对照表左边是经典操作系统概念右边是智能体平台概念操作系统概念智能体平台对应物相似度系统调用syscall工具调用function calling高进程/线程任务执行循环agent loop中内存管理上下文窗口与记忆管理中高文件系统外部知识库与记忆存储中调度器任务规划与路由策略低权限系统工具权限与指令边界中内核态/用户态模型内/模型外系统低设备驱动工具适配器tool adapter高但对照表好看不代表等式成立。两者最核心的差异是确定性的等级。操作系统里同一个系统调用给定相同输入行为是可复现的而智能体平台的每一次工具调用背后都是一次概率采样同样的输入、同样的模型版本跑十次可能有十种不同的路径。这个差异决定了 Harness 的工程目标和传统操作系统内核完全不同内核追求的是确定的资源分配Harness 追求的是在不确定的行为上盖出确定的业务结果。1.3 谁更像“内核”谁更像“外壳”另一个容易混淆的地方是模型和 Harness 各自的角色。严格说模型更接近一块可以执行“意图”的计算硬件而 Harness 才是真正把这块硬件组织成平台的软件层。你可以把模型想象成一颗通用计算芯片它能力强不强是芯片的制程问题而芯片要被焊接在什么主板上、总线怎么走、散热怎么解、驱动怎么装这些全是 Harness 的活。在这个视角下“智能体即操作系统”的说法其实不算准确至少目前不算。更准确的说法是模型提供了类似 CPU 的通用计算能力Harness 提供了把这种能力变成可调度、可追踪、可控资源的系统软件。未来即使模型能力翻几倍这套系统软件依然稀缺因为它解决的从来不只是“模型会不会”而是“系统行不行”。2. Harness 到底要接住什么问题2.1 没有 Harness 的智能体距离生产差在哪把裸模型接上几个工具塞一段 system prompt就声称“智能体完成”——这是过去一年我在各种项目评审里看到次数最多的状态。跑 Demo 确实没问题演示的时候模型按部就班地调用工具、给出答案看起来非常聪明。可一旦接入真实业务问题会接二连三地冒出来。我归纳下来裸奔智能体在真实场景里最典型的死法有五种上下文爆炸多轮任务里历史记录和中间结果越积越多最终超窗模型开始“失忆”甚至把早先的工具结果当成最新状态。工具调用失序模型跳过了前置校验直接执行了本该被拦截的危险操作或者陷入调用循环一个错误被反复重试。不可观测整条任务链跑完了你只能看到最终输出完全不知道中间模型依据什么做了决策出了问题没法复盘。难以回退任务跑了一半失败没有快照、没有事务概念只能整条重来而且重来一次结果还不一样。成本失控一次简单查询被模型拆成了七八次工具调用令牌消耗是人工操作的好几倍。2.2 Harness 的定义不是模型而是包住模型的那层系统“Harness”这个词借自控制系统语境英文原意是“马具、挽具、约束装置”。它做的事情不是提供动力而是把动力引导到正确的方向上同时防止动力失控。用在智能体场景里Harness 指的是所有位于模型之外、围绕模型构建的工程组件运行循环、记忆管理、工具接入、权限校验、观测日志、评测基线、安全护栏、人机协作界面。换句话说Harness 是智能体的“外部操作系统”模型在里面只是一个执行单元。这个区分对工程团队特别重要如果你把精力全部押在换更强的模型上而 Harness 稀烂那么每次换模型都像换了一台新引擎却沿用旧底盘系统照样跑不稳反过来Harness 扎实哪怕模型能力落后半代整个平台的稳定性、可维护性和成本结构依然能打。2.3 为什么这个领域值得单独叫“工程”有段时间大家把这类工作叫“提示工程”但我觉得这个名字低估了它。Prompt Engineering 解决的是单次对话里“怎么把话说清楚”的问题而 Harness Engineering 解决的是“一个由智能体驱动的软件系统如何长期稳定地运转”的问题。前者是措辞艺术后者是系统架构、调度、容错、评测、治理这些经典软件工程话题在新载体上的重演。把它称为工程意味着它有设计模式、有故障模型、有性能指标、有最佳实践是可以被教授、被评审、被积累的。这也恰恰是很多智能体项目失败的根因团队把智能体当成一个“模型应用”而不是一个“系统工程”。立项时只关心模型准确率上线后才发现稳定性、可观测性、成本控制全都没设计最后只能靠运维半夜救火。3. 一个生产级 Harness 由哪些模块组成3.1 核心模块速览我自己搭过几个智能体平台也拆过别人家的框架最后沉淀下来的模块清单大致是这一套模块职责类比任务运行循环管理单次任务的执行步骤、状态流转、终止条件进程调度记忆层分层管理工作记忆、场景记忆、长期知识内存与外部存储工具注册与适配把外部 API 包装成模型可调用的结构化接口设备驱动上下文工程压缩、检索、排序、注入控制每次调用的上下文组成cache 与内存管理权限与边界校验工具调用是否合法、可控、可撤销安全内核可观测性全链路追踪、日志、成本与延迟监控系统监控评测基线离线数据集上的回归测试与在线指标单元测试与监控恢复与降级重试、回滚、人工接管、兜底方案高可用机制下面挑几个最容易做砸的模块展开说。3.2 任务运行循环最容易被低估的难点很多人以为智能体的核心是模型的那次决策实际上模型每做一次决策都需要一个运行循环来承接。循环体负责从目标出发反复执行“理解当前状态—决定下一步—调用工具或输出—记录结果”的迭代直到满足终止条件或达到步数上限。这里的关键是状态机设计每一步都必须有明确状态包括等待用户输入、执行工具调用、等待工具返回、正在规划、已终止、已人工接管。任何一个状态缺失并发场景下都会炸出竞态问题。我踩过的坑是多个分支任务同时朝同一个外部系统发起写操作结果因为运行循环没有做状态合并同一个订单被两条任务链各处理了一次。后来加了一个全局“目标锁”才把并发的重复执行挡下来。另一个容易被忽略的设计是终止条件收敛。模型在没有明确终态定义时很容易陷入“看似在推进实际在绕圈”的执行模式。Harness 至少要设置三重终止机制步骤数上限、重复动作检测、外部进度信号。少一重线上就会多一重成本暴增的隐患。3.3 记忆与上下文工程上下文窗口就是智能体的“内存”模型本身不保留跨任务的状态所有的“记忆”都由 Harness 代管。我通常把记忆分成三层工作记忆存放当前任务内的中间结果和对话过程场景记忆记录同一用户或同一项目在一段时间内的偏好与状态长期知识从业务文档、知识库里检索出来的事实性内容。分层的主要原因很实际上下文窗口是稀缺资源不能一股脑全塞进去。我的默认策略是只把工作记忆完整保留场景记忆按相关性抽取长期知识走向量检索取 TopN。每一轮调用前Harness 都要做一次“上下文组装”把这三部分按预算压缩拼装。上下文预算是这里最有价值的工程概念每个进入上下文的 token 都在占用窗口也在增加决策噪声。我会给每轮调用设定硬预算比如系统指令占 15%、检索内容最多占 40%、历史记录占 30%、剩余留给模型输出。超预算时优先丢历史细节而不是丢当前任务上下文。3.4 工具接入层与权限边界给智能体装“驱动”和“保险丝”工具层负责把外部能力变成结构化接口这跟操作系统的设备驱动异曲同工。每个工具都需要定义清晰的入参出参 schema、幂等性策略、超时时间、错误返回格式。其中幂等性怎么强调都不过分智能体天然会有重试行为如果你的接口不幂等重复调用就会产生重复订单、重复扣款这类事故。我见过不止一个团队接口没有做幂等结果模型一次超时重试业务系统里多出一整批重复单据最后靠人工一笔笔核对清理。权限边界是另一层保险丝。工具本身应该只暴露最小必要权限Harness 在模型发出调用请求时做一次强制校验校验不通过就拦截并返回给模型一个结构化解释让模型可以换一条路径。而不是让模型直接拿到万能接口靠 prompt 去约束它“不要乱来”。真实经验是prompt 约束在大多数情况下只是建议硬编码的权限校验才是警察。3.5 人在回路与中止恢复Harness 的应急按钮无论 Harness 做得多么完善总有模型搞不定的场景。生产级系统必须预设人工介入的通道当任务出现不确定性高危动作、成本超阈值、或者模型连续失败达到上限时Harness 应主动挂起任务并把控制权交给人类。注意挂起不是终止任务应该是可恢复的。我的做法是为每个任务维护一份可序列化的快照记录当前状态、已执行步骤、调用历史、上下文摘要。人工介入完成后可以把修正后的决策重新注入运行循环继续跑。这个机制的价值在我经历的所有智能体事故里都得到了验证没有快照和恢复机制的任务出问题只能整条重跑成本翻倍就算了重跑结果还未必一致有快照的十分钟内就能把任务从错误轨迹上拉回来。提示任务快照是智能体平台的“撤销键”。在设计 Harness 的第一天就加上快照能力比事后补要便宜一个数量级。4. 可观测性、评测与护栏Harness 的隐形地基4.1 为什么可观测性必须排在模型前面智能体的运行过程是典型的非线性执行每一步走的路径都不一样普通日志只能看到输入输出无法还原模型中间为什么选了这条路径。所以要为智能体专门设计一套链路追踪体系记录每一轮决策的时间、模型的推理摘要、工具调用入参出参、上下文快照、关键节点的规则判断结果。有了这些数据你才能回答业务方最常问的三个问题这个任务为什么这么贵这个错误为什么发生了这个结论的依据是什么没有链路追踪的智能体平台本质上就是黑盒而业务系统最忌讳黑盒。我甚至建议把链路追踪当作文档智能体每次执行留下的 trace比任何设计文档都诚实地记录了系统的真实行为。当前很多编排框架在展示层做得花哨但真正深入到 trace 级别的细节记录往往需要自己补。这个钱省不得。4.2 评测基线Harness 的单元测试很多团队在选模型时非常认真做了很多 Benchmark但自己搭的智能体却没有任何回归评测这有点讽刺。智能体系统的每一次改动包括换模型、调 prompt、改记忆策略、加工具都可能导致行为漂移。如果没有评测基线你根本不知道改动是变好还是变坏。我推荐的基线结构分三层第一层是离线数据集准备一批有标准答案的任务样本跑完记录成功率、工具调用准确率、最终答案准确率第二层是模拟环境给智能体提供一套可控的外部系统 Mock验证它在各种边界输入下的表现第三层是线上影子指标把生产流量复制一份到新配置上对比观察成本、延迟、人工介入率的变化。人工介入率是我最看重的指标没有之一。它直接反映 Harness 是否在有效地托底介入率低说明系统自主完成度高介入率上升说明最近一次改动把系统搞“虚胖”了。这个指标跟模型分数一样值得每天盯。4.3 护栏的三个层次安全护栏不是一道墙而是三道。第一道是工具接入侧过滤也就是权限最小化前面讲的强制校验就是这一层。第二道是行为层规则引擎实时监控工具调用的模式比如检测到模型要对生产环境执行写操作但事前没有经过人工确认就直接触发告警并挂起任务。第三道是输出侧审核过滤检查模型生成的内容和最终行动计划是否越过合规边界确保交到用户手里的东西干净、可控。这三道护栏分别对应工具、行为和内容三个层面少任何一道系统在真实业务里都会出现你完全不想看到的场景。以我的观察很多智能体事故本质上不是模型“变坏”了而是护栏层次缺失模型行为没变是底层权限太宽、上层又没有审核把一次小概率失误放大成了线上事故。5. 审慎者的反驳Harness 会不会只是过渡态5.1 反例一模型能力增强会吃掉部分 Harness我必须承认这个方向存在一个明显的反驳随着模型能力增强很多原来需要 Harness 承担的工程逻辑正在被模型原生能力覆盖。长上下文窗口的扩大让“上下文压缩”这类模块的需求变小模型对工具调用的原生支持越来越好让工具适配层变得越来越薄未来如果模型具备更强的记忆与规划能力Harness 的不少组件会不会被整体替代这个反驳有一定道理但它忽略了一点模型的每一次能力上移不是让系统软件消失而是把系统软件的重心往上推。操作系统历史里也有类似的事早期硬件管理是程序员手写汇编后来出现编译器和操作系统并不是某个组件“吃掉”了全部工程而是工程以新的形态出现在更高的抽象层。Harness 的某些模块会贬值但围绕可靠性、成本、治理的工程需求不会消失只会换一种形式存在。5.2 反例二智能体跑在操作系统之上而不是取代操作系统更硬的反驳是智能体并不是操作系统它只是运行在传统操作系统之上的一个应用运行时。智能体本身完全依赖传统 OS 提供的进程、文件、网络能力它连自己赖以生存的基础设施都不掌控凭什么说自己是操作系统这个质疑很难彻底推翻。一个合理的修正立场是未来计算平台的核心与其说是智能体取代操作系统不如说是智能体成为新的应用模型而承载它的平台依旧跑在传统 OS 网络之上。值得关注的不是“谁的优先级更高”而是“应用开发者面向哪一层编程”。如果未来开发者写的是“目标描述 工具声明”而不是手写函数调用流程那么真正的平台层就是承载这种编程范式的 Harness。它成了应用开发者眼中的“操作系统”至于底下有多少传统内核反而不重要。5.3 我的修正叫“应用运行时”比叫“操作系统”更准确如果必须给我的立场找一个精确坐标我会说把 Agent Harness 称为“智能体时代的应用运行时”比叫“操作系统”更准确。它管不了硬件管不了网络它管理的是模型、上下文和工具这三个应用层资源。但恰恰是这三个资源正成为未来应用最核心的依赖。这也解释了我为什么仍然认为这门工程值得投入凡是被大量应用依赖的资源就一定会沉淀出一套系统性的管理软件。CPU 依赖催生了操作系统数据库依赖催生了数据库管理系统模型和工具依赖正在催生智能体 Harness。叫它操作系统还是运行时只是命名之争工程本质是一样的把稀缺的、不稳定的、多头管理的资源封装成一套稳定的、可编程的、可治理的抽象。6. 如果你决定动手做 Agent 平台我的工程建议6.1 从单一任务闭环开始别一上来就做“通用智能体”我见过太多团队的第一版架构图是“一个中枢大脑连接所有系统”的万能平台结果往往连一个具体任务都跑不稳。我的建议是反过来找一条价值明确、边界清晰的任务链比如“自动整理客服工单生成摘要并标记优先级”先把它跑成全闭环。闭环里把运行循环、工具接入、上下文管理、权限校验、日志追踪全部走一遍。这个过程的产出不是 demo而是一套可复制的工程模式。单一闭环跑通以后你才会真正理解 Harness 里哪些模块是刚需哪些是过度设计。这时候再把闭环复制到第二条、第三条任务上用相同的机制服务不同的业务平台化才自然成立。平台是从一个痛点长出来的不是从一张架构图画出来的。6.2 评测先行模型可以换Harness 必须沉淀如果能给一条建议我会说把评测基线和可观测性放在任何“智能”功能之前。因为模型迭代极快今天觉得厉害的模型三个月后可能已经不是最优选择但你沉淀下来的评测数据、链路追踪、错误模式分析会一直保值。每次换模型只需要重跑一遍基线对比新旧行为差异这种工程资产会越攒越厚。我自己的团队把这种方式戏称为“给模型上户口”每次引入新模型或新配置都在评测体系里登记一份行为档案。时间久了这些档案比任何模型宣传材料都有参考价值。某次新模型在通用评测上分数全面领先但一跑我们自己的基线发现它在“多工具连续调用”这一类任务里成功率掉了六个点直接避免了仓促上线。6.3 上下文预算是真正的成本账很多团队的智能体账单爆炸不是模型单价贵而是上下文预算失控。一个任务里反复注入重复历史一次调用塞进十万 token 无关内容这种事每天都在发生。Harness 里必须有一个专门的上下文组装层每一轮调用前都做一次预算核算什么内容必须进、什么内容可以压缩、什么内容应该从检索层按需取。这个层做好成本通常能降一半以上稳定性也会同步提升因为上下文干净了模型被无关信息干扰的概率就低了。我见过一个项目只做了上下文去重和按需检索单次任务平均 token 消耗直接降了 60%准确率反而略微上升。这就是把工程做在模型之外的典型收益。6.4 自建还是用框架按控制点决定对小型团队我建议直接站在现成的编排框架上起步把精力放在业务闭环和评测上。但对中大型团队有两个控制点值得自建一是可观测性与追踪体系这决定了你对系统行为的认知深度二是权限与治理机制这决定了你敢不敢把智能体放进核心业务。这两个点如果被通用框架的黑盒逻辑挡住后面一定会出现不得不推倒重来的局面。选型时还有一个常见误区只看框架的“明星功能”忽略它的终止机制、错误处理、人工接管能力。这三个能力决定了一个框架能不能扛真实业务而不是能不能跑通 demo。照着这个清单去筛选框架比看宣传页管用得多。6.5 最后分享一个习惯我入坑智能体工程之后养成了一个习惯每解决一个线上事故都会把事故过程整理成一篇简短复盘记录根因、排查路径、修复动作顺带把 Harness 缺的那块补上。半年下来这些复盘成了团队在新人培养和架构评审时最好用的材料。原因很简单智能体系统的行为是概率性的线上事故一定会来区别只是你用不用它来升级系统。Harness 的价值不在于消灭所有不确定性那是做不到的它的价值在于让每一次不确定性暴露之后系统都能变得更强一点。这大概就是这项工程和传统操作系统工程最大的共鸣了。
