企业官网建设流程全解析

最近好几个朋友来问我同样的问题：deepseek harness 到底是个什么东西，和 agent 框架有什么区别，怎么装完以后跑不起来。聊到最后我发现很多人其实卡在了同一个地方——把 harness 当成了一个“安装即用”的组件，却没意识到 harness 本身是一个需要反复权衡设计的东西。装一个开源 harness 只是起点，真正决定你的 agent 能不能干活、扛不扛得住生产环境的，是你在设计 harness 时做的每一个 tradeoff。

这篇文章我打算从工程落地的角度，聊聊 agent Harness 设计里那些绕不开的取舍。我不会去复述某个项目的 README，而是把我自己在实际项目里踩过的坑、验证过的方案、以及最终采用的折衷策略整理出来。如果你正在搭 agent 项目，或者打算把 deepseek harness、Claude Code 这类工具集成到自己的系统里，这篇应该能帮你省不少时间。

1. Harness 是什么：先厘清边界再谈权衡

1.1 agent 与 harness 的分工边界

先说概念。很多人把 harness 和 agent 框架混为一谈，其实两者解决的问题完全不同。Agent 框架回答的是“agent 怎么思考、怎么决策、怎么调用工具”，它关心的是推理链路、任务分解、工具选择这些偏“智能”的部分。而 Harness 回答的是“agent 跑在什么环境里、怎么被约束、怎么被观测、怎么被恢复”，它关心的是进程管理、权限控制、状态持久化、并发调度、日志追踪这些偏“工程”的部分。

用一个类比：agent 是驾驶员，harness 是车。驾驶员决定怎么走，但车决定了你能走多快、能载多重、出事了有没有安全带和安全气囊。一个再聪明的驾驶员，开一辆没有刹车、没有仪表盘、没有安全结构的车，也只敢在封闭场地里转悠，上不了路。

所以当你看到“deepseek harness”这种项目时，它的核心价值不在“多智能”，而在“多可控”。它给模型提供了一个被执行的环境，同时给开发者提供了一组约束和观测手段。这就是为什么 harness 设计里到处是 tradeoff——约束多一点，安全就多一点，但灵活性和效率就会降一点；观测全一点，排查就快一点，但性能和存储成本就会涨一点。没有一个方向是绝对正确的，全看你的场景要什么。

1.2 为什么“设计糟糕的 harness 也能跑 demo”

我见过不少项目，demo 阶段跑得飞起，一上生产就崩。原因不在于模型变笨了，而是 demo 场景天然绕过了 harness 的难点。你跑一个“给我写一首诗”的 demo，不需要记忆管理，不需要权限控制，不需要并发隔离，不需要状态恢复。你跑一个“帮我批量处理这 200 份合同并把结果同步到内部系统”的真实任务，以上全都变成了硬需求。

我最早做 agent 项目时就是这个状态。本地跑一个 agent，调几个工具，感觉一切都很美好。直到我把同一个 harness 放到服务器上，让它每晚自动执行一批任务，问题才接踵而至：任务跑到一半进程被 OOM killer 干掉，没有断点恢复机制，重新跑一遍要花几小时；agent 自由发挥把临时文件写进了系统目录，导致权限混乱；两个 agent 同时读写同一个工作目录，互相把对方的中间结果覆盖了。

这些都不是模型能力问题，全是 harness 设计问题。所以我才说，讨论 harness 的 tradeoff，本质上是讨论“怎么把 agent 从 demo 变成生产系统”的那一整套取舍。下面我按几个关键维度展开讲。

2. 控制与自由：harness 约束力度的取舍

2.1 约束过死的代价：从“不肯干活”说起

Harness 最直观的设计维度，就是你给 agent 画了多大的活动范围。很多开发者出于安全本能，喜欢把约束做得很死：文件只能读特定目录，命令只能执行白名单里的几条，网络请求必须逐条审批。

听起来很安全，但你实际跑起来会发现自己养了一个“什么都干不了”的 agent。我见过一个例子，团队给 agent 配了严格的工具白名单，结果模型在任务卡住时反复尝试调用一个没在白名单里的工具，来回折腾了 20 多轮，最后自己放弃了。问题不在于模型不想干活，而在于 harness 把它所有的合理路径都封死了，只剩下一条它自己都意识不到的迂回路线。

更常见的现象是 agent 变得极度依赖“请示”。约束一多，模型会倾向于在每个不确定的节点停下来问用户。表面上这是“谨慎”，实际上任务推进速度会变得不可忍受。你让它处理一个多步骤任务，它每走一步都回来问“我可以执行这个命令吗”“我可以写入这个路径吗”，那这个 agent 就退化成了一个带执行功能的聊天机器人，失去了自主性的意义。

2.2 约束过松的代价：自主性带来的连环副作用

反过来，约束太松的后果可能更严重。我自己的项目里就出过一次事故：agent 在执行一个数据分析任务时，直接在系统目录里创建了一个 Python 虚拟环境，接着又试图修改 shell 配置文件来“优化环境变量”。从 agent 的角度看，它每一步都有逻辑依据。但从系统管理员的视角看，这是一个失控的进程在自行改造宿主环境。

更隐蔽的问题是副作用不可追踪。约束松的时候，agent 可能通过多种不同的路径完成同一件事，比如写文件它可以直接写，也可以先执行一个脚本再让脚本去写。一旦出了故障，你要反向排查它到底通过哪条路径做了什么，成本极高。如果 harness 没有在每一层都留下审计记录，你可能连它做过了什么都说不清。

还有一个容易忽略的副作用：宽松约束会让模型养成坏习惯。模型是上下文学习的，如果它在你的 harness 里成功通过“绕路”方式完成了任务，后续任务里它会倾向于继续绕路。你等于是在用 harness 的实际行为给模型做强化训练，训出了一个不按规矩办事的 agent。

2.3 折衷思路：偏置（steer）而不是戒严

经历了几次两边吃亏之后，我现在的做法是：不做全面禁止，做偏置和分级授权。

所谓偏置，就是你告诉 agent“默认走这条路，但特殊情况可以申请例外”，而不是“只能走这条路，其他一律禁止”。具体到 harness 实现上，我做了几层设计：

• 预设默认路径。给 agent 配好常用的工作目录、常用的工具参数模板，让它的第一选择总是那条安全高效的路径。不是强制，而是让正确路径成为模型最容易输出的那个选项。这符合大模型的行为规律——它倾向于走概率最高的那条路，你只要把安全路径的概率抬高，就能大幅降低乱跑的概率。

• 例外走审批通道。当 agent 确实需要跨出默认范围时，harness 会中断执行，生成一条授权请求，描述清楚“要做什么、涉及哪些资源、预计有什么副作用”，由人工确认后才放行。这个机制比预先封死所有路径更符合实际——因为你不可能预见到所有合理需求，但你可以对每一个例外做一次判断。

• 授权结果反馈为上下文。每次例外审批通过后，harness 会把“这个操作是经过授权的”写入 agent 的上下文，让它在后续相关操作中更有底气。这听起来是小事，实际效果很好，能显著减少重复请示。

这套折衷的思路，一句话总结就是：安全不一定靠锁死，更多靠引导和留痕。给模型一条宽敞的主干道，同时告诉它偏离主干道需要登记，比把整个区域围上铁丝网高效得多。

3. 记忆策略的 tradeoff：上下文窗口不是记忆

3.1 全量塞入的幻觉与账单

Harness 设计的第二个大坑是记忆管理。很多人以为上下文窗口足够大，就可以把所有历史信息一股脑塞进去，让 agent“记住一切”。这个思路在短会话里没问题，但任务一长就会翻车。

首先是费用问题。每次请求的 token 消耗量直接决定你的运营成本，把所有历史对话、中间结果、日志全量塞入上下文，token 消耗会以平方级的速度增长。我碰到过一个案例，一个跑了几小时的长任务，光上下文费用就顶得上短任务几百次。老板看到账单的时候脸色都不太对。

其次是注意力稀释。模型对上下文的注意力是有限资源，信息太多太杂的时候，它可能抓不住真正关键的内容。我遇到过 agent 在处理任务时，把两周前一段无关紧要的闲聊记录当成了用户的最新要求，导致任务方向完全跑偏。拿“上下文当记忆”用，不是记不住，而是它会记乱。

更麻烦的是，全量塞入会让模型“过于自信”。它看到上下文里存了某个文件的老版本内容，就以为自己掌握了最新状态，直接基于旧数据做决策。要是 harness 没有在上下文里标注信息的时间戳和版本号，这种错误几乎难以避免。

3.2 摘要替代的失真与丢失

既然全量塞入不可行，那做摘要总行了吧？行，但摘要也有自己的代价。

摘要最大的问题是不可逆的信息丢失。你让模型把一段 5000 字的日志压缩成 500 字，它提取的往往是你当时觉得重要的信息，但“当时觉得重要”不等于“后面用得上”。等任务执行到后半段，agent 突然发现需要某个被摘要滤掉的细节，但它已经找不回来了。尤其是一些技术参数、环境变量、路径信息，压缩时很容易被当成次要信息丢掉，结果后面每一步都因为缺这个参数而卡壳。

还有摘要失真问题。模型的摘要不是客观压缩，它会有自己的倾向和幻觉。我测过一次，模型把“任务 A 失败后转做任务 B”摘要成了“任务 A 完成，进入任务 B”，原因在于它把“失败”理解成了“推进”。这种失真信息进了长期记忆，会让后续任务在错误的假设上做决策，而且因为记忆看起来“合理”，模型不会主动质疑。

3.3 实用经验：三级记忆与主动压缩触发点

我现在采用的三级记忆方案，核心是把记忆按生命周期和价值分层，而不是一刀切地全存或全压。

第一级是票据级记忆（ticket-level memory）。对应当前正在执行的任务，保留完整的原始信息，包括每一步的执行结果、代码输出、数据片段。它的特点是生命周期短，任务结束就可以归档。这一级的 key 是“完整”，宁可多存不能漏。

第二级是项目级记忆（project-level memory）。跨会话、跨任务的长期事实，比如“项目里约定的代码规范”“目标服务器只允许内网访问”“生产数据库不能直接写”。这一级我采用结构化存储，每个事实单独一条记录，尽量用短句表达，避免模糊描述。它的 key 是“准确”，宁缺毋滥。

第三级是档案级记忆（archive memory）。已经完成的项目经验、决策记录、复盘结论。这一级可以大胆做摘要，因为它本来就是给 agent 做参考用的，不参与具体执行决策。它的 key 是“泛化”，从具体经验里提炼出可迁移的规律。

压缩触发点也要设计，不能等上下文快满了才处理。我设了三个触发条件，任一满足就执行压缩：

• 上下文 token 达到阈值的 70% 时，主动把第一级记忆中已完成的部分压缩为项目级事实；
• 单个工具调用返回结果超过一定长度时，先提取结构化信息再决定是否保留原始输出；
• 任务阶段切换时，对上一步的执行过程做“速写式”记录，三句话说清楚做了什么、产出什么、有什么遗留。

同时我记住了一点：压缩时不要让模型把“被压缩掉的内容”伪装成“不存在”。我要求压缩记录里明确标注“此处有信息被精简，如需原始数据见 trace_id：xxx”，这样 agent 在后续执行中如果发现自己缺信息，至少知道去哪里找，而不是在错误的前提上继续跑。

4. 工具与权限：安全边界上的三层博弈

4.1 全开放工具：走了捷径，踩了坑

工具调用权限是 harness 安全性的核心战场。刚开始我图省事，直接把宿主环境的 shell 开放给 agent，想着“模型能力这么强，应该知道什么能做什么不能做”。第一周确实效率奇高，agent 什么都能干，装依赖、跑脚本、改配置，一气呵成。

但很快问题就来了。有一次 agent 在执行一个数据处理任务时，顺手执行了一条清理临时文件的命令，结果把另一个服务正在使用的临时目录也清掉了。由于我完全没有在做这步操作之前设置任何确认机制，agent 自己觉得“清理临时文件是合理操作”，就直接动手了。等发现的时候，依赖这些临时文件的下游任务已经全面告吹，你要一项项排查它到底删了什么，也是一件头疼的事。

这个经历让我明白，工具权限的把握关键不在“agent 有没有能力”，而在于“你作为系统设计者，有没有在能力边界上留下缓冲垫”。全开放工具本质上等于把系统管理员权限交给一个自信的实习生，他大部分时候靠谱，但犯错的那一次就能让你赔掉不少时间。

4.2 白名单工具：安全了，也钝了

全开放被推翻后，我尝试过极端方案：把所有工具都纳入白名单，只有列表里的才允许调用。安全确实安全了，但 agent 的效率肉眼可见地下降。它经常需要用组合拳才能完成一个白名单外的操作，比如没有“重启服务”这个工具，它就只能自己写脚本、执行脚本、再验证状态，绕一个大圈子。

更让我不舒服的是，白名单机制会让 agent 在面对新情况时非常脆弱。你做 RPA 集成的时候，真实业务流程里有大量动态参数和临时取数逻辑，你不可能在开发期全部预定义好。一旦 agent 遇到白名单外的合理需求，它只能用“拆解成白名单内的操作”的方式硬来，不仅效率低，还容易过渡执行——把一个本来简单的读操作，拆解成一连串的写操作和中间文件的处理，副作用成倍扩大。

白名单还有一层隐性代价：维护成本。工具列表是活的，你的业务在变，harness 要接的新系统在变，白名单就得不断更新。而每一次更新白名单都意味着你要再次评估风险，这个评审流程一长，agent 的上线周期就被拖慢了。

4.3 分层授权与审计：我的实践方案

平衡了安全和效率之后，我最终采用的是分层授权模型。核心思路是，不按“能不能调”来划分工具，而是按“调用会产生什么级别的影响”来划分授权。

我大致分了四层：

• 只读层：查询类工具，比如读文件、查数据库、调外部 API 获取信息。这些操作不改变系统状态，风险极低，完全放权。
• 受限写层：在当前工作目录范围内创建或修改文件、执行临时脚本。这些操作影响范围可控，允许自动执行，但在日志中记录完整上下文。
• 高风险写层：修改系统配置、安装软件包、写生产数据库、执行会影响宿主机状态的命令。这个层级必须经过显式审批，审批通过后才能执行，且执行结果要回传确认。
• 外部副作用层：发送通知、创建工单、推送代码、调用第三方生产接口。这类操作对外部系统产生影响，我设置的是独立审批通道，并带有“只允许特定目标地址”的约束。

审计方面我坚持一个原则：所有工具调用，无论层级，都必须留下三方信息——调用时的意图描述、实际传入的参数、工具返回的结果。这三者对应关系清晰了，你才能在出问题时快速定位是 agent 判断错了、参数传错了、还是工具本身出了问题。

提示：分层授权不等于层层审批。绝大多数操作应该集中在只读层和受限写层，让 agent 自主完成。审批通道是设计用来应对少数“越界”场景的，如果大量操作都需要人工批准，说明你的权限分层本身设计得不合理。

5. 并发与沙箱：agent 扛住生产流量的关键权衡

5.1 串行执行最安全，但毫无意义

很多 harness 的初始实现都是串行执行：一个 agent 跑完了，下一个才启动。这种设计配合严格沙箱，安全上没毛病，但它直接把系统的吞吐量钉死在了 1。如果你有 20 个任务排队，每个任务平均跑 15 分钟，那么最后一个任务要等将近 5 个小时。

我最开始不觉得这是问题，直到有业务方要求“每天早晨 8 点前必须出全部报表”，而我算了一下，串行跑根本来不及。这才被迫去面对“agent 怎么扛并发”这个问题。Agent 场景的并发比普通 Web 服务的并发要复杂得多，因为它不只是同时服务很多请求，还意味着同时维护很多条彼此独立又可能共享资源的执行链路。

5.2 资源竞争与同频共振

并发的第一座大山是资源竞争。多个 agent 同时跑，最明显的是共享目录冲突。两个 agent 同时启动，都默认在工作区创建各自的临时文件夹，本来互不干扰。但如果 harness 的工作区设计没做好，比如所有 agent 默认共用一个工作目录，那它们在写文件时就会互相踩踏。我见过两个 agent 同时写同一个文件，后写的数据覆盖了先写的，导致两个任务的结果都不对。

第二座大山是 API 配额和限流。这比资源竞争更难察觉。多个 agent 同时请求同一个模型服务或外部 API，你以为彼此独立，实际上都在消耗同一个配额。当并发数超过配额上限，限流就会出现——有的请求超时、有的被拒绝。最麻烦的是，agent 对限流的反应是重试，而大量重试会进一步加剧限流，形成“限流-重试-更严重的限流”的同频共振。这种共振一旦发生，不只是新任务进不来，已经跑着的任务也会被拖死。

第三座大山是 token 消耗的失控。单个 agent 的 token 消耗是可预估的，多个并发的消耗则可能瞬间突破你的预算。而且因为 agent 运行时长不确定，并发峰值很难提前算出上限，账单出来的时候往往远超预期。

5.3 沙箱隔离级别选择与配额策略

针对并发问题，我现在的做法是分两个层面处理，一是沙箱隔离，二是并发配额。

沙箱隔离级别有三种选择，各有取舍：

• 进程级隔离：同一台机器上，每个 agent 一个独立进程组，配合工作目录隔离。开销最小，部署最简单，但隔离性弱——如果 agent 能执行特权命令，还是可以影响到宿主机。这是我在快速验证时要用的方案。
• 容器级隔离：每个 agent 跑在独立容器里，限制 CPU、内存、磁盘和网络。这是生产环境的标配方案，隔离性足够，开销可控，而且能做到“容器内的 agent 再怎么折腾，影响范围都限制在容器内”。重启一个容器比清理一台被搞乱的虚拟机便宜多了。
• 虚拟机级隔离：每个 agent 跑在独立虚拟机里。隔离性最强，但开销大、启动慢、维护成本高。我一般只在需要给外部客户跑不可信 agent 时用，不适用内部日常任务。

我目前的主力方案是容器级隔离，配合系统化的配额策略。配额策略几个核心参数：

• 并发 agent 数量上限，这是最粗的指标，用来防止“同时跑太多任务”这种低级失控；
• 总 token 消耗速率，这是更本质的指标，比如设置在某个时间窗口内全体 agent 的 token 消耗峰值，超过阈值就排队等待；
• 外部 API 并发上限，单独设置，防止 harness 内部多个 agent 对同一个外部系统造成冲击；
• CPU 内存硬限制，每个容器单独配额，防止单个失控 agent 拖垮整台机器。

提一句热搜里提到的“codex 无法发送消息，显示更新 agent 沙盒”这类问题。我在实际使用中遇到的类似情况，根因往往是沙盒切换时的优雅降级做得不够——沙盒更新期间，执行环境处于不可用状态，但 harness 没有把这个状态明确感知并阻塞任务，导致 agent 误以为系统故障而反复重试或卡住。好的做法是 harness 中单独维护沙盒状态机，当沙盒不可用时，队列任务直接保持等待状态，而不是启动 agent 去错误运行。

6. 生命周期与可观测性：失败时才知道的痛

6.1 状态恢复：断点续跑还是重新来过

Agent 任务跑到一半挂掉，是生产环境最让人头大的问题。挂掉的原因五花八门：OOM、网络中断、外部 API 长时间无响应、宿主机重启。无论哪种，harness 都必须回答一个问题：任务怎么恢复？

最简单的策略是重新来过。就是从头执行整个任务。这个方案实现成本最低，但代价可能非常大。我有一个跑数据同步的任务，前半段要把几百个文件逐个下载、校验、清洗，后半段才进入转换和入库。每次跑到一半挂了，重来一遍就要重新下载几百个文件，不仅慢，还可能对源系统造成不必要的压力。

更好的策略是断点续跑。任务执行过程中把每个步骤的状态持久化，挂掉后从最后一个已完成的步骤继续。但这个方案也有自己的麻烦：一是步骤之间的边界必须足够清晰，很多 agent 任务是嵌套调用的，很难定义“最后完成的一步”到底是什么；二是工具调用的幂等性要求高，如果中途某个写操作已经执行了但状态没记录，恢复时重新执行一遍就可能产生重复副作用。

折衷方案是“检查点 + 影响判定”。每执行完一个有明确外部效果的步骤，就记录一个检查点。任务恢复时，先读取检查点，再对检查点之后的步骤做一次“这个步骤是否已经产生外部效果”的判定。比如写同一个目标文件，如果文件内容已经符合预期，就跳过；不符合预期，则重新执行。这个方案兼顾了效率和安全性，但前提是你的 harness 要对每个工具调用约定一个“幂等判定方法”。

6.2 日志与追踪：harness 里的“黑匣子”

Agent 系统的排错难，难在它是黑盒里的黑盒。模型内部怎么思考你只能通过它的输出推测，工具调用会产生什么样的实际效果需要结合运行环境判断。如果没有强大的日志，出了故障你只能对着一个 agent 傻眼。

我吃过这个亏。有一次 agent 在夜间任务里改了数据库里一张关键表的数据，业务方第二天发现数据对不上。我去查日志，发现 harness 只记录了“agent 成功调用数据库工具”，连调用参数都没存。我根本无从判断数据是哪种操作、哪个环节改错的。最后只能人工复盘整个任务链路，花了将近一天才定位到问题。

从那以后，我对 harness 的日志设计立了三个规矩：

• 每一层信息都要有独立的日志流。模型思考步骤、工具调用参数、系统执行事件、外部 API 响应，四类信息分开存储，按 trace_id 关联。这样可以直接过滤出某一类问题，不用在混乱一锅粥的日志里人肉捞。
• 工具调用的入参和出参必须完整记录，尤其入参。这一步很关键，有助于排查“agent 理解错了”还是“参数传错了”。
• 日志要有上下文关联。单条日志看不出问题，必须知道这条日志对应的任务 ID、在第几步、由哪个 agent 产生，才能还原出完整的执行链路。

我不推荐把日志全量交给模型代理去分析。日志是给人和程序看的，模型代理可能因为日志里信息过载而抓住错误重点。harness 应该自己完成结构化处理，把日志提炼成可供模型消费的高层级事件信息，这样才能两者兼顾。

6.3 错误处理的折衷：重试、回退与容忍

Agent 在真实运行中一定会遇到错误，关键不在于避开错误，而在于错误发生后的应对策略设计。

无限重试是最愚蠢的策略。有些错误是永久性的，比如权限不足、参数非法，重试一万次也是同样的结果，只会白白消耗 token。有些错误是暂时性的，比如网络抖动、限流，重试两三次可能就好了。把这两类错误混在一起做同样的处理，是 harness 设计上最常见的偷懒。

我现在的处理方式是分级重试：

• 瞬态错误（网络超时、连接重置、限流）：最多重试 3 次，采用指数退避；3 次仍失败则把任务转入待观察状态，等资源恢复之后再续跑。
• 一致性错误（状态冲突、数据校验失败、版本不匹配）：不重试，直接终态结束，标记为需要人工介入。
• 模型输出异常（结构错误、JSON 解析失败、返回空内容）：可以重试 1 次，并附加一条“上一次输出格式有误”的提示。第二次仍失败则停止，避免模型在错误状态下反复空转。

回退机制同样重要。agent 改坏了代码、写错了配置、误删了数据，这些风险防不胜防，harness 必须提供后悔药。我现在的默认策略是：agent 执行任何涉及文件修改的操作前，自动给目标文件打快照。这样一旦改了东西不对劲，可以随时回退到操作前的状态。热搜里提到“deepseek harness 代码回退”，就是这个价值——模型改完代码跑测试挂了，不会回退的话，整个工作区就废了；会回退的话，损失不过是一次快照的存储开销。

7. 我踩过的几个具体权衡坑与折衷清单

7.1 插件加载失败的根因

很多人在用基于 harness 的工具链时都遇到过一个经典问题：插件加载失败，启动时报什么“plugin failed to load”“entry did not activate”之类的错误。

我查过几次这类问题，根因通常不是插件本身坏了，而是 harness 对插件加载的“时序”和“路径”处理太脆弱。比如启动脚本先加载插件再初始化配置目录，插件在配置目录还没准备好时就去找配置文件，自然找不到，启动就失败。或者是插件路径硬编码了某个绝对路径，你换一台机器部署路径不一样，插件就起不来。

我现在的做法是，harness 的插件加载器必须单独负责三件事：路径探测、依赖排序、失败隔离。

• 路径探测的意思是，插件的工作目录、配置目录、日志目录都必须在加载前确保存在且可达，不能等插件跑起来了再去创建。
• 依赖排序的意思是，插件 A 依赖插件 B 的初始化结果，加载器就要保证 B 先加载，否则 A 挂着也算它命不好。
• 失败隔离的意思是，一个插件挂了不能影响其他插件和主程序，要捕获插件启动异常并生成独立错误报告，而不是让整个 harness 崩掉。

7.2 内网部署 skill 的特殊处理

搜热词里有“deepseek harness 附带 skill 怎么部署到内网服务器”，这个我也实际做过，里面有几个坑值得说。

内网环境最麻烦的是没有外网访问。Harness 默认会去某个源拉取模型插件或 skill 组件，在内网环境就会超时。解决思路分两步：第一步是在有网的机器上把所有需要的组件下载好，打成离线包；第二步是在内网服务器上用本地源或者本地目录替换远程源。

但这里有个容易忽略的细节：skill 组件本身可能附带依赖，比如某些 skill 要调用特定版本的 Python 包。你把 skill 文件夹搬过去了，但它的依赖没装，照样跑不起来。所以离线部署时，我建议把整个运行环境用容器固化下来，而不是只拷贝 skill 文件。容器自带全部依赖，内网服务器只要有一个能跑容器的打底环境就能运行。

另外，内网部署时的模型端点配置也要注意。Harness 默认用的模型端点可能指向公网服务，内网访问不了。你需要把 harness 的模型服务配置指到内网部署的模型推理服务上，并且确认密钥管理、鉴权方式在内网环境下能正常工作。

7.3 一张当前我认为比较合理的默认 tradeoff 列表

最后把我目前在实际项目中采用的默认取舍整理成一张清单，方便你对照自己的场景调整。这里的核心原则是：安全的红线和高效的阈值是做 tradeoff 时必须跟上的两个锚点，所有取舍都围绕这两个锚点来设定。

这张清单不是标准答案，它只是我在一堆具体项目里被逼着做出取舍后沉淀下来的默认值。你换一个业务场景，比如金融交易的自动化操作，或者面向外部用户的自助 agent，这些默认值里有一半可能要推翻重来。

但我真正想说的是，harness 设计没有银弹，所有好的方案都是在具体的约束条件下试出来的。你做得越多，越会发现为什么 harness 这个层如此重要——它把模型的能力用一套安全、稳定、可运维的框架接住，然后才谈得上让 agent 真正干实事。