企业官网建设流程全解析

先说我的结论：Harness不会被模型完全吃掉，但确实会被吃掉一大块。准确一点说，模型正在吃掉Harness里所有"需要动脑子"的部分，剩下的部分是那些跟聪明不聪明没关系、纯粹靠工程纪律才能活下去的东西。这场分工变化，恰好也解释了为什么"Harness会不会被模型吃掉"这个问题本身，就是理解整个AI应用架构演进的最佳切入点。

这篇文章不是要给你推荐某个具体的Harness框架，也不是要带你从零搭一个Agent工程。我想做的是把问题拆开：模型到底吃掉了Harness的哪一层？哪些地方它根本吃不动？真正活下来的Harness会变成什么形态？最后落到一个实打实的判断方法上，帮你决定自己的项目里哪些逻辑该放心交给模型，哪些必须留在骨架层。无论你是刚接触Agent开发的初学者，还是已经在做复杂Agent工程的从业者，这套分析思路应该都适用。

1. 先搞清楚"被吃掉"是什么意思：Harness和模型的边界在哪

要讨论这个话题，第一步得把"Harness"是什么、它站在模型的哪个位置说清楚。不然聊到最后大家都在说两件不同的事。

1.1 Harness在Agent架构里的真实角色

Harness这个词直译是"马具"，工程里一般叫"外壳"或"骨架"。放在AI Agent的语境里，它指的是套在模型外面那一整套非模型的运行机制，典型职责包括这么几类：

• 上下文组装与管理：决定哪些内容放进提示词、哪些不放进，放进去之后怎么压缩、怎么截断。
• 工具注册与调用：模型说出"我要调用某个工具"之后，harness负责找到工具、传参、执行、把结果回填给模型。
• 循环控制：模型输出的内容是否结束、是否要继续调用下一轮工具，由harness判断并驱动循环。
• 状态与记忆：跨多轮对话的会话状态、用户偏好、消息历史，存在哪里、什么时候写入、什么时候清理。
• 可靠性与运维：重试、限流、超时、日志、审计、安全边界，这类事情和模型本身的"智能"无关，但决定系统能不能长期稳定跑下去。

而模型层负责的是另一件事：把一串输入token变成一个输出token序列，也就是"理解语义、做出决策、生成内容"。它不负责把工具真正执行掉，不负责记录日志，也不负责在多轮对话之间维护状态。

边界大概是：模型是大脑，harness是身体和四肢。大脑决定要不要捡起杯子，身体负责真的把杯子拿起来，还要负责拿完之后记住杯子放哪了。

1.2 "被吃掉"这个说法到底在指什么

社区里说"模型会不会把harness吃掉"，通常有三层含义：

第一层是功能替代。原来由harness实现的某个功能，模型原生能力直接覆盖了，harness的这层代码可以删掉。

第二层是价值转移。某个功能仍然存在，但核心逻辑从外部工程代码移到了模型内部，外部只是包了一层薄薄的胶水。

第三层是架构简化。因为前两层发生，整个系统不再需要那么复杂的骨架，Agent可以退化成"模型加几个API调用"的简单组合。

这三个层面你得分清楚。很多人看到模型长上下文大涨、原生函数调用越来越成熟，就喊harness要死了，说的其实是第一层。但如果看到第一层就全盘否定harness，那就忽略了第二层和第三层里更本质的东西：系统级职责并没有消失，只是转移和重新分配了。

我比较喜欢用一个传统软件工程的类比：早年很多框架帮你封装了数据库连接、事务管理、日志埋点。后来语言和数据库自身能力变强了，有些封装确实被"吃掉"了，但事务管理、连接池、日志收集这些概念并没有消失，而是下沉成了基础设施的一部分。Harness也一样，被吃掉的是"作为独立框架层存在的方式"，不是它承载的那些职责本身。

2. 模型确实在吃：上下文、工具调用与提示词优化

咱们先承认现实，模型真的吃掉了一部分harness职责。这部分要是不认，后面很多判断都站不住。

2.1 长上下文吞掉了滑动窗口和大部分检索脚手架

大概两三年之前，Agent工程里有一个绕不开的话题：上下文窗口不够用。

早期的模型窗口从2K、4K起步，稍微一长就装不下。为了应对这个问题，社区发展出一整套"上下文工程"方法：滑动窗口策略、关键信息抽取、摘要压缩、分段检索、向量数据库召回。很多harness框架把大量代码花在这上面，目的只有一个：在窗口有限的情况下，尽可能保留对话中最有价值的信息。

而现在，主流模型的长上下文已经到128K、1M甚至更有余量。什么叫1M？大概相当于一本书的体量。在这个量级下，很多早期的滑动窗口和实时摘要逻辑确实变得不那么必要了。你不需要小心翼翼地裁剪历史，直接把对话记录塞进去，模型也能理解。这就是长上下文能力对harness的"吃"。

但注意"吃掉"的范围：它吃掉的是"为了适配小窗口而做的妥协策略"，但并没有吃掉"决定放什么进上下文"这件事。哪怕窗口有1M，你也不可能真的把整个公司的文档库都塞进去。1M也有上限，而且随着上下文长度变大，处理和响应时间、成本都在涨。至于哪些内容值得进窗口、哪些该放记忆区、哪些可以进行离线索引，这个问题在长上下文时代反而更考验架构设计，后面第4章细讲。

2.2 原生函数调用让工具调度逻辑下沉到模型层

第二口啃在了工具调用上。

早期的Agent框架要实现工具调用，需要一整套外部机制：规定工具描述的JSON Schema、写解析器把模型输出转换成结构化调用、设计"模型一会输出文本一会输出工具指令"的双模解析逻辑、还要处理模型强行在文本里输出工具指令的边界情况。

现在模型原生支持function calling了，模型会在输出端直接产生结构化的工具调用指令，参数严格对齐你的schema。harness层绝大多数解析、纠错、格式转换逻辑都可以删掉。模型自己完成"决定调哪个工具"和"生成参数"这两步，harness只需要老老实实执行。

这里被吃掉的是"决策和格式化"层面的能力，留下来的还有"执行"。而执行恰恰不是模型擅长的事，这是第3章要讲的：执行涉及权限、可靠性、审计，这些和聪明不聪明无关。

2.3 提示词优化不再依赖人工反复改写

第三个被吃的是提示词工程里的一大部分。

你看热搜词里有个"deepseek harness提示词优化插件"，这类插件的目标就是帮你把prompt调得更好。早期做法是人肉调prompt：加few-shot例子，改措辞，调整指令顺序，测试不同温度参数。这个阶段大量harness功能围绕prompt版本管理、模板引擎、自动评测来做。

但现在模型能力变强之后，很多人工prompt工程被极大简化了。模型自己能从错误反馈里调整行为，甚至你可以让模型去优化自己的系统提示词。原来需要人来抠的那些措辞细节，价值在下降。你可以说是模型把老一代prompt优化器吃了，也可以说是工程重心的转移：从"调模型话术"变成"调数据、调工具、调节奏"。

我见过不止一个项目在模型迭代之后删掉了上百行精心设计的prompt模板，效果反而更好。这不是说prompt完全没用了，而是说"提示词优化"作为harness的核心卖点，已经撑不起一个框架的存在价值了。

这三口吃完，确实已经让很多harness框架的"智能层"变得空心化。如果你的harness唯一的价值就是帮模型补脑，那它被吃掉是早晚的事。

3. 吃不动的地方：系统、可靠性与算力约束

但模型也有明显吃不动的地方。这些地方恰恰是harness最有生命力的部分，也是很多纯模型能力无法取代的工程职责。

3.1 解释性与审计：模型给不了可复用的决策轨迹

第一个吃不动的东西是审计。

企业级Agent系统要求你回答一个问题：这个Agent今天上午为什么调用了一个外部接口，传参是谁批准的？模型自己可以告诉你一句解释"因为用户需要查天气"，但这种解释既不稳定、也不可复用。你需要的是结构化的日志：哪一步、什么工具、什么参数、什么返回、故障在哪、耗了多少token，这些全部要被记录、查询、回溯。

模型层不可能给你这个保证，因为模型每次推理是独立的，它不维护"我之前承诺过什么"的账本。账本天然要放在harness里。你可以说模型很聪明，但审计要的不是聪明，是确定性。

这也是为什么很多客服、金融、医疗场景的Agent架构极其保守：模型可以换、可以升级，但外面的审计层是铁打的。没有这层，模型越聪明越糟糕，因为聪明模型做出的决策更复杂，审计难度反而更高。

3.2 多系统编排、认证与权限边界：骨架层的护城河

第二个吃不动的是跨系统的编排。

一个真实Agent不会只调用一个模型，它要调用业务API、数据库、消息队列、第三方服务、内部工单系统。这些系统的认证方式千奇百怪，有些还要求你严格记录谁在什么时候碰了敏感数据。安全边界、权限检查、密钥管理、风控策略，这些东西没一个能靠"模型更聪明"来解决。

举个具体例子：Agent要帮用户创建一个云上实例。模型可以决定"该创建实例了"，但到底用哪个账号的密钥去调API、这个账号有没有权限在目标可用区创建中大型实例、失败之后该不该自动回滚——这些判断不能交给模型即兴发挥。模型输出层根本没有身份边界的概念，它只有token概率。

工程里这叫“防呆设计”：即使模型犯糊涂、幻觉、或者被prompt注入攻击诱导它调用一个危险动作，harness层的权限策略也要拦住它。想象一下模型是一个很有主见的新员工，你当然希望他能主动思考，但公司的门禁系统不会因为新员工聪明就给他万能钥匙。

Harness和Agent的区别也体现在这里。Agent是"模型+循环+工具的思考执行单元"，Harness是把这个单元放进整个系统里的骨架：谁能调用它、它能碰到什么资源、它的调用记录在哪。没有骨架的Agent就是一个裸奔的大脑，再聪明也进不了生产环境。

3.3 模型繁忙、限流与成本：弹性能力必须留在系统层

第三个吃不动的地方，来自一个很接地气的场景：模型繁忙，请稍后重试。

你去看热搜词里那串error report，message: 模型繁忙,请。这太真实了。模型服务总有抖动、限流、超时、过载的时候。任何直接调用模型、没有外部骨架支撑的应用，在这种时刻就是全盘瘫痪。

Harness的价值在这里体现得淋漓尽致：请求排队、超时重试、失败降级、结果缓存、熔断开关、把一次大请求拆成多个小请求。这些工程弹性机制跟模型的智能水平完全无关。你不可能期望模型自己在繁忙时还能帮你"想想怎么绕过繁忙"，因为此时你根本调不到它。

成本控制也归这一层：大模型调用是要花钱的。做缓存、做语义去重、做局部刷新，选择便宜的小模型做前置分类、只在必要时用大模型推理，这种路由策略是harness的活。模型本身不会主动帮你省钱，它只会忠实地烧钱。

所以在实际项目里我见过一个有趣的现象：越是重度使用模型的应用，它的外围失败处理代码越厚。模型是个能力放大器，能力越强，放大出来的错误也越需要外围来收口。

4. Harness的演化方向：从脚手架到编排骨架

既然模型吃了智能层，又吃不动系统层，那活下来的harness会长成什么样？我的判断是：它不再是一个用来"补脑"的脚手架，而是一个专注编排与可靠性的骨架。这个转变已经在发生，我可以给你看三个具体演化方向。

4.1 上下文组装与压缩继续留在harness

有人觉得长上下文时代就不需要做上下文工程了，这是误解。长上下文不代表"什么都可以塞"。

先看成本：同样一个token，放在输入和放在输出的价格不同，但输入长了整体的延迟和费用一定上去。就算模型能读1M，你每次读1M的代价是响应慢、花费高，用户等不起。再看质量：上下文越长，信噪比越低，无关信息反而会稀释模型的注意力，尤其当关键信息埋在一堆历史记录中间。这个问题学术界叫"lost in the middle"——中间位置的信息容易被忽略。

所以harness在上下文方面的工作会从"怎么装更多"变成"怎么装得更准"：优先级排序、结构化摘要、分层记忆、把长文档先拆后取。长上下文只是扩大了容量，没有取消筛选的必要性。我把这个变化概括成一句：以前harness是搬运工，现在是策展人。

4.2 技能目录与插件系统成为硬需求

热搜词里有一连串和插件、技能相关的内容：deepseek harness插件、deepseek harness附带skill怎么部署到内网服务器、deepseek harness 插件推荐。这说明对使用者来说，"给Agent装技能"正在变成像"给手机装App"一样的产品化操作。

背后逻辑是：模型的通用能力不可能覆盖所有垂直场景，总需要外部工具来补足专业能力。而工具管理这件事会越来越标准化。一份工具清单、一套描述Schema、一个注册中心，再加一个可插拔的执行环境，这就是Harness里的"应用商店"。

这部分为什么吃不动？因为工具本身是模型之外的实体。模型再强，它不会去调用自己的API，也不该去调用你的生产系统。谁来管理工具的版本、谁来处理工具报错、谁来确认工具返回结果可靠性，这些必须落在骨架层。而且同一套技能资产应该能跨模型复用，换一个模型品牌，技能目录不用从头搭，这也是骨架层的价值。

一提内网部署就更明显了：模型可以千变万化，但企业内网的系统资产、数据库凭证、网关规则，只能靠工程骨架去适配。技能不只是一个prompt模板，它背后连着实际业务系统的接口，而接口的安全性只能靠harness保证。

4.3 多代理协调、记忆与反馈回路留给骨架层

最后说说复杂Agent形态下的harness。单Agent的时候，模型+工具+循环就可以跑，骨架的必要性还不那么刺眼。但当你做多代理协作系统，Agent之间要传递消息、共享记忆、协调执行顺序、判断全局终止条件，这时候没有骨架就寸步难行。

模型可以负责"这一段任务怎么思考"，但"这个Agent的产出发给哪个Agent""两个Agent的结论冲突了以谁为准""一条任务链在第七步超时了怎么整体回退"，这类编排逻辑放到模型输出是不负责任的。你需要一个确定性的骨架来兜底。

这就引到一个常被混淆的概念：Agent和Harness的区别。Agent是模型驱动的智能单元，它在某个具体任务上有自主决策能力。Harness则是容纳Agent、定义Agent之间的通讯协议、生命周期和资源边界的那套机制。你可以有一百个很聪明的Agent，但没有Harness，它们就是一百个无法互相协作的孤岛。

我做一个简单的对比表格，把模型、Agent、Harness分清楚：

5. 给使用者的务实切分：什么交给模型，什么留在harness

聊了这么多，最后落到实操：你自己的项目里，功能边界怎么切？

5.1 三问判断法

我平时做架构评审的时候会用一个三问判断法，比对着特性列表一条条过更管用。

第一个问题：这件事的成败靠的是"认知判断"还是"工程确定性"？如果你的诉求是"判断用户这句话背后的意图""决定下一步调用哪个工具更合理"，这些可以大胆交给模型，甚至期待模型未来更聪明之后做得更好。如果你的诉求是"这个操作必须且只能执行一次""这个资源必须有权限校验才能访问"，那就不能依赖模型实时发挥，必须放在骨架层固化成代码。

第二个问题：这个逻辑是否需要跨会话、跨系统保持一致状态？模型默认是无状态的，每次调用都是全新的推理。如果某个决策需要依赖上个月的历史记录、需要和另一个系统共享一份状态快照，这种状态一致性问题是harness的领地。模型可以在对话中"表现得"记得，但它不承担一致性责任。企业系统不可能接受"Agent这次记得，下次情绪化忘了"。

第三个问题：出错之后，你需不需要追责和回滚？只要答案是"需要"，那就意味着审计、日志、版本化管理必须存在，而这些天然在harness里。说实话，模型出错是常态，没有审计的话，模型越聪明、出错越难查。

5.2 落到具体方案：配置、插件与部署的实操建议

基于这套判断，我给你几条在实际使用deepseek harness之类工具时可以马上落地的操作建议。

第一，把提示词当作配置而不是代码来管理。哪怕模型越来越强，系统提示词、角色设定、工具描述这些最好放在独立的配置文件里，不要散落在业务逻辑里。这样模型升级后你只需要调整配置，不需要动代码。比如：

# harness提示词配置片段 system_prompt: role: "customer_service_assistant" constraints: - "必须先确认用户身份才能查询订单" - "涉及退款操作时必须同时通知风控系统" tools: ["query_order", "create_refund", "notify_risk"]

这个文件的维护者是工程，不依赖模型，"先确认身份再操作"这类安全规则永远放在骨架层。

第二，插件的选择标准不是"看起来智能"，而是"边界清晰"。一个合格的harness插件应该声明输入输出、声明权限范围、声明失败行为。如果一个插件声称自己能"包办一切智能对话"，那它反而容易出问题。真正稳的插件是那种"只管一个动作、动作描述足够清楚、失败时能稳定抛出异常"的实体。

第三，内网部署时先剥离对公网模型的硬依赖。在小模型可以胜任的环节上跑本地小模型，只有复杂推理才调用远程大模型，这样网络波动、外部限流对你的影响会小很多。顺便解决"模型繁忙"的体验问题：宁可降级响应也不能无限等待。

我自己的一个习惯是：每次模型版本升级之后，重新审视一遍harness里那些"为了补足模型短板"而存在的代码，能删就删；但那些"为了保证系统安全稳定"的代码，一道都不要动。前者是模型已经吃掉的，后者是模型永远吃不掉的。

5.3 最后聊一点个人体会

我做Agent工程这几年，见过不少人把项目失败归因于"模型不够聪明"，但真正的问题往往是外围骨架太薄：没有好的上下文管理、没有权限控制、没有失败重试，再聪明的模型也跑不出稳定的产品。反过来也见过模型升级之后，原来复杂的prompt技巧一夜之间失去意义的项目，删除冗余代码时会有一种说不出的畅快。

所以你问我harness会不会被模型吃掉，我的实际体会是：它会被吃掉"智能"那部分，然后以"系统骨架"的身份继续活着。与其纠结框架会不会消亡，不如早点把架构里"靠聪明才能运行"的部分尽量压缩，把"不靠聪明也能稳定"的部分建设好。这个方向走对了，不管模型怎么进化，你的系统都不会被时代甩下去。