你在B站刷到的“Harness架构”可能有三种完全不同的指向有人说是CI/CD持续交付平台有人说是测试框架里的Test Harness还有人拿着DeepSeek、Codex、OpenCode的源码讲Agent运行时。到底谁是对的其实都对但在2026年的大模型应用开发语境下Harness最值得关注的含义是“AI Agent的运行时外壳”。它正是从“能聊天的模型”走向“能自动干活的Agent”之间最重要、也最容易被忽略的一层工程抽象。这篇文章给出一个明确判断模型决定Agent的智能上限Harness决定Agent的工程下限。以前我们调模型API关注的是提示词和参数现在构建Agent真正决定稳定性、安全性和可维护性的是承载Agent循环的那套框架。这篇文章会先厘清Harness在三种语境下的区别再拆解Agent Harness的核心组件用Python从零实现一个最小Harness然后讲生产级架构的实战要点、常见问题排查、最佳实践最后整理一套能直接用于面试的高频问题与答题思路。不玩梗也不吹什么“99%成功率”理解原理才是真正的底气。1. 这篇文章真正要解决的问题先说说现在的普遍困境。很多人已经会用大模型API做RAG、做对话机器人代码也能跑通但一到构建Agent就频繁翻车模型明明知道该调用哪个工具却总把参数传错任务稍微长一点上下文就被中间结果塞满工具一旦报错整个任务直接中断更麻烦的是模型可能会执行危险命令而代码里根本没有权限控制。这些问题看起来是模型不够聪明实际上大部分是Harness设计不到位。2026年再去看编程Agent的生态会发现Anthropic、OpenAI、DeepSeek等团队都已经把“Agent外壳”作为开源和研究的关键方向。社区里搜索“deepseek harness”“codex harness”“opencode架构源码”本质上都是在研究同一个问题模型外面的那层系统应该怎么设计。这才是Agent从Demo走向产品化的分水岭。如果你只是会调用ChatCompletion接口面对“如何让Agent稳定执行多步任务”这类问题很难给出有深度的答案。因此这篇文章最值得读的人群是正在做AI应用开发的工程师、后端和全栈开发者、系统架构设计师以及准备大模型应用开发岗位面试的求职者。读完你至少能获得四个能力第一准确解释Harness是什么以及它解决什么问题第二独立设计一个最小Agent Loop第三知道生产环境中Harness需要哪些核心组件和配置第四能用清晰的逻辑回答面试官关于Agent架构、工具调用、上下文管理和安全设计的追问。先明确一点任何声称“面试成功率99%”的说法都不必当真。面试官真正考察的是你能否把概念讲清楚、能否把设计落到代码里、能否预判生产环境中的坑。Harness恰好是能同时展示这三点的主题。2. Harness 的概念辨析与演进背景2.1 三种语境下的HarnessHarness这个单词在技术圈出现得很早但不同领域含义差别很大。如果不先厘清语境看教程时很容易张冠李戴。第一种是DevOps领域的Harness平台。它是一套软件交付平台核心能力包括持续集成、持续交付、Feature Flag、云成本管理等常用于微服务架构和分布式系统中的发布编排。第二种是测试领域的Test Harness中文常译作“测试基架”或“测试壳”负责为被测系统提供输入、收集输出、控制测试执行环境。第三种就是本文重点讨论的Agent Harness它指的是承载大模型Agent运行的一套运行时框架负责管理Agent循环、工具调用、上下文、安全、可观测性等能力。类型核心对象解决问题典型场景DevOps Harness平台软件交付流水线发布效率、灰度、回滚CI/CD、GitOps、特性开关Test Harness被测系统测试输入输出控制、结果断言单元测试、集成测试、回归测试Agent HarnessLLM Agent运行时循环控制、工具调用、安全、观测AI编程、自动化任务、多Agent协作2.2 为什么2026年Agent Harness成为焦点一个明显的趋势是底层模型API正在趋于同质化而Agent应用之间的差距逐渐转移到“模型外面的系统”。也就是说大家都在用类似水平的模型但有人能把任务成功率做到90%有人只能做到30%区别往往就在Harness的工程细节上。从技术演进看早期Agent实现多是把“调用模型—解析输出—执行工具”写在一个脚本里。这种写法在演示时没问题一旦进入真实项目就会遇到状态管理混乱、错误处理缺失、安全边界模糊等问题。于是工程界开始把这层逻辑抽象成独立的运行时框架也就是Harness。像Claude Code、OpenAI Codex这类编程Agent本质上都是在一个成熟的Harness之上运行而DeepSeek等模型陆续开放之后开发者可以自己基于模型底座构建Harness用来实现代码生成、自动调试、任务规划等场景。这里可以打一个类比把大模型比作发动机Harness就是整车。发动机决定动力上限但方向盘、刹车、仪表盘、安全气囊、导航系统决定了这台车能不能安全、舒适、可控地把你送到目的地。只看发动机参数就像只盯着模型效果指标而Harness决定了整个系统能不能可靠运行。3. AI Agent Harness 的核心原理3.1 Agent Loop 闭环Agent Harness最核心的机制是一个被称为Agent Loop的闭环循环。每一次循环包含四个阶段感知、决策、行动、观察。感知阶段Harness把用户任务、历史消息、工具执行结果组装成模型输入决策阶段模型根据当前信息决定下一步动作可能是调用某个工具也可能直接输出最终答案行动阶段Harness解析模型输出校验参数调用对应的工具观察阶段把工具执行结果作为新的消息追加到上下文然后进入下一轮循环。这个机制和传统的Workflow有本质区别。Workflow是预定义的代码路径例如“先查数据库再调接口最后发通知”每一步是固定的Agent Loop则是模型在每一轮动态决定下一步做什么。正因为路径不确定Harness才必须承担起“把握方向”的责任既要给模型足够的自由度又要通过最大步数、格式校验、权限限制等手段防止它失控。3.2 Harness 需要解决的关键问题如果把Agent Loop展开会发现Harness至少要解决六类问题。状态管理多轮工具调用结果如何正确累积如何保证模型能看到完整且有序的执行轨迹。上下文管理模型上下文窗口有限如何在超过限制时进行截断、摘要或分层存储。工具管理工具如何注册、参数如何校验、执行失败后如何把错误信息回传给模型。安全控制哪些操作允许执行哪些操作需要人工审批如何在容器或沙箱中隔离危险操作。可观测性每个步骤的模型输出、工具参数、执行结果、耗时和成本都要有完整记录。错误恢复单步失败后是重试、跳过、换个策略还是直接终止任务。这些能力单独拿出来都不难理解难的是组合在一个Harness里并保持稳定。一个没有Harness的Agent本质上只是“模型接一个while循环”而一个合格的Harness要能处理各种异常路径保证任务可追踪、可回滚、可审计。从工程角度讲没有Harness的Agent只能算Demo有Harness的Agent才可能成为产品。4. Harness 核心组件深度拆解4.1 调度引擎调度引擎是整个Harness的主循环负责控制Agent的执行流程。它决定何时调用模型、何时调用工具、何时停止以及如何处理超时和异常。设计调度引擎时最重要的三个参数是最大步数、单步超时时间和连续失败阈值。最大步数防止Agent无限循环单步超时防止某个工具调用卡死整个任务连续失败阈值则防止模型在同一个错误上来回打转。实际项目中这些参数通常要按任务类型单独配置而不是全局写死。4.2 工具注册与执行器Agent需要调用外部能力这些能力以“工具”的形式注册到Harness中。工具注册中心维护一份工具清单包括工具名称、参数Schema、描述信息和对应的执行函数。模型在决策时会根据工具的描述选择调用哪个工具Harness在收到模型输出后先校验参数格式再执行工具函数。工具层最常见的坑有三个一是工具描述写得太模糊模型不知道该选哪个二是参数校验不严格模型传错类型或漏传必填项三是一个工具内部实现过重融入了大量业务逻辑导致难以测试和复用。建议每个工具只做一件事用清晰的文档字符串描述功能和参数并在执行前做严格的Schema校验。4.3 上下文管理器上下文管理器负责维护整个Agent对话历史。它在每次循环中把系统提示词、用户任务、模型输出、工具结果组装成消息列表。真实项目中必须处理上下文溢出问题常见策略有滑动窗口、摘要压缩、外部记忆和向量检索。滑动窗口保留最近N条消息简单但有信息丢失风险摘要压缩是在接近窗口上限时用模型把历史推理过程压缩成摘要外部记忆则是把关键事实存入向量数据库按需检索。生产环境中通常组合使用最近的完整消息保留较早的消息转为摘要关键数据放外部存储。上下文管理器还要负责防止“上下文污染”比如工具返回内容过大时应该截断或只提取关键信息避免挤占模型窗口。4.4 安全与权限层安全是Harness与普通脚本最大的区别之一。模型输出的只是文本Harness在把它变成真实动作之前必须做权限校验。常见做法包括命令白名单、路径白名单、容器沙箱、人工审批流和审计日志。一个合理的安全模型是“默认拒绝”没有明确授权的操作一律不允许执行。比如文件删除、git push、生产环境部署等高风险操作应当要求人工确认。笔者在工程实践中见过不少Agent事故几乎都出在“图方便放开了权限”这个环节。安全设计必须在架构初期就纳入而不是等出问题后再补。4.5 可观测性与追踪Agent任务的执行轨迹比普通接口调用复杂得多因为它涉及多轮模型调用和工具调用。可观测性层需要记录每次模型请求的输入输出、每次工具调用的参数和结果、每步耗时和Token消耗并且把整条任务链路串联起来。推荐的做法是采用OpenTelemetry标准为每个Agent任务分配一个Trace ID每一步都作为一个Span记录。这样在任务失败时可以快速定位是模型决策错误、工具执行异常还是上下文管理问题。没有可观测性的Harness调试时会非常痛苦因为Agent的失败往往不是一处报错而是一连串错误的累积。4.6 模型适配层为了不绑定某个具体厂商Harness通常会抽象出一层模型适配器统一封装不同模型的调用协议。无论是DeepSeek、OpenAI还是本地部署的开源模型对Harness来说都只提供“输入消息列表输出结构化结果”的能力。模型适配层还负责处理供应商差异比如是否支持JSON Mode、是否支持函数调用协议、计费单位是什么。设计模型适配层时要注意不要把模型特有逻辑泄漏到上层。例如某个模型不支持函数调用适配层应该把工具列表转换成文本描述而不是让上层代码感知这种差异。这样上层Harness的代码可以保持稳定切换模型时只需新增一个适配器。5. 从零实现一个最小 Harness 实战5.1 目标和设计思路理论讲再多不如跑一个最小实现。这一节我们用Python实现一个非常精简的Agent Harness它包含工具注册中心、模拟模型和一个简单的Agent Loop。为了让大家在没有API Key的情况下也能运行这里用一个MockLLM模拟模型输出核心目的是理解Harness的调用协议。设计上遵循三个原则模型输出必须是结构化JSON便于Harness解析工具执行结果以observation消息回传给模型形成闭环循环必须设置最大步数防止死循环。这个最小实现去掉了很多生产级细节但保留了Harness最本质的骨架。5.2 核心代码实现创建一个文件harness_demo.py代码如下。# harness_demo.py import json class ToolRegistry: 工具注册中心负责维护工具列表并提供按名调用能力。 def __init__(self): self._tools {} def register(self, func): 用装饰器方式注册工具。 self._tools[func.__name__] func return func def get_tool_names(self): return list(self._tools.keys()) def call(self, name: str, args: dict): if name not in self._tools: raise ValueError(f工具不存在: {name}) return self._tools[name](**args) registry ToolRegistry() registry.register def add(a: float, b: float) - float: 加法计算工具 return a b registry.register def multiply(a: float, b: float) - float: 乘法计算工具 return a * b class MockLLM: 模拟LLM按预置步骤返回JSON用于本地演示Agent Loop。 真实项目中chat() 内部应把 messages 发送给大模型接口 并开启 JSON Mode 或函数调用协议来保证输出可解析。 def __init__(self, steps): self._steps iter(steps) def chat(self, messages): return next(self._steps) class SimpleHarness: 最小Agent Harness调度模型、解析动作、执行工具、回填结果。 def __init__(self, llm, registry, max_steps10): self.llm llm self.registry registry self.max_steps max_steps self.history [] def run(self, user_task: str): self.history.append({role: user, content: user_task}) for step in range(self.max_steps): # 1. 决策调用模型获取下一步动作 response self.llm.chat(self.history) print(f[step {step 1}] 模型输出: {response[content]}) # 2. 解析要求模型返回可解析的JSON try: action json.loads(response[content]) except json.JSONDecodeError as e: raise RuntimeError(f模型输出不是合法JSON: {e}) # 3. 判断是结束还是调用工具 if action[type] finish: return action[answer] # 4. 行动执行工具调用 result self.registry.call(action[name], action[args]) # 5. 观察把工具结果追加到历史并保留模型消息 self.history.append(response) self.history.append({ role: tool, name: action[name], result: result, }) raise RuntimeError(f超过最大执行步数 {self.max_steps}) if __name__ __main__: steps [ {role: assistant, content: json.dumps( {type: tool, name: add, args: {a: 1, b: 2}})}, {role: assistant, content: json.dumps( {type: tool, name: multiply, args: {a: 3, b: 4}})}, {role: assistant, content: json.dumps( {type: finish, answer: 计算完成结果是 12})}, ] harness SimpleHarness(llmMockLLM(steps), registryregistry) print(harness.run(请计算 (12)*4))这段代码的关键点有三个。第一模型输出的JSON结构被设计成两种类型tool表示调用工具finish表示返回最终答案第二ToolRegistry用装饰器注册工具后续新增工具只需要写一个函数并加上registry.register第三每次工具调用后都把模型的决策和工具结果追加到history里这样下一轮模型能感知到之前发生了什么。5.3 运行与验证在命令行中运行python harness_demo.py预期输出如下[step 1] 模型输出: {type: tool, name: add, args: {a: 1, b: 2}} [step 2] 模型输出: {type: tool, name: multiply, args: {a: 3, b: 4}} [step 3] 模型输出: {type: finish, answer: 计算完成结果是 12} 计算完成结果是 12如果运行成功说明整个Agent闭环已经跑通模型决定调用工具、Harness执行工具、结果回填、模型再次决策、最终输出答案。这里最需要注意的是模型输出格式。真实项目中直接让模型输出任意文本再解析JSON失败率会很高更稳妥的做法是使用模型的JSON Mode或者在提示词中严格限定输出Schema。把它替换成真实模型时只需要修改MockLLM.chat()让它携带self.history调用大模型接口并返回结果。其他部分比如工具注册、循环控制、结果回填都不需要改动。建议读者先把这个最小Harness跑通再逐步加入上下文管理、安全校验和日志追踪。6. 生产级 Harness 架构实战要点6.1 多Agent协作与任务编排单个Agent在简单任务上表现不错但复杂任务通常需要多个角色协作。常见的模式是Planner、Executor、Reviewer三层结构Planner负责把大任务拆解成子任务Executor负责执行具体步骤Reviewer负责检查结果是否满足要求。这种设计减少了单个Agent的上下文压力也便于针对每个角色单独调优。多Agent带来的新问题是通信和共享状态。最简单的方式是共享一个任务黑板各Agent在黑板中读写子任务状态复杂一点的会用事件驱动架构让Agent通过事件总线异步交互。无论是哪种方式生产环境都要给任务加状态机明确“待执行、执行中、成功、失败、已取消”等状态避免因为并行执行导致状态错乱。6.2 权限审批与人机协同生产级Harness不能把全部控制权交给模型。建议把工具按风险等级分为三档低风险工具可以直接执行比如读文件、搜索代码中风险工具需要记录审计日志比如写临时文件高风险工具必须人工审批比如删除文件、推送代码、部署生产环境。审批流可以接入IM或工单系统审批信息要包含工具名称、参数、风险说明和执行人。人机协同不是“人肉挡枪”而是把模型的关键决策置于人工监督之下。对于一次编码任务Agent可以先修改代码并生成Diff由人来Review后合并对于数据操作任务Agent先生成SQL由DBA审批后执行。这样做的好处是既保留Agent的效率又避免不可控的操作进入生产链路。6.3 上下文压缩与长任务记忆长任务的上下文管理是生产环境最容易踩坑的地方。很多问题表面上是“模型变笨了”实际是历史消息太多太杂关键信息被淹没。推荐的方案是三层策略第一层保留最近几轮完整消息保证模型能处理当前上下文第二层对更早的对话做摘要保留推理结论和关键数据第三层把事实性内容存入外部记忆例如向量数据库或Key-Value存储在需要时检索注入。压缩时机也很重要。可以设定阈值比如消息总Token数达到上下文窗口的70%时触发压缩。压缩过程本身也调用模型因此要把“压缩任务的Prompt”设计好确保摘要不丢失关键信息。还有一点容易忽略工具返回结果本身可能很大建议在进入历史之前就做截断而不是等积累后再压缩。6.4 全链路追踪与失败恢复生产环境中Agent任务通常运行时间较长可能有几分钟甚至几小时过程中任何一步都可能失败。全链路追踪能让你在问题发生后快速定位失败恢复则降低任务整体失败的代价。建议每个任务都有唯一的Task ID日志中记录每一步的模型请求ID、Token消耗、工具调用参数和耗时。失败恢复策略包括单步重试、跳过当前工具、切换策略、重新规划子任务。例如某工具连续失败两次Harness可以要求模型换个工具或用其他方式完成任务而不是直接报废整个任务。6.5 一个生产级配置示例下面给出一个生产级Harness的YAML配置示例展示核心参数如何组织。harness: agent: mode: plan_execute # 可选: react / plan_execute max_steps: 50 # 单任务最大步数 max_tokens_per_step: 2048 # 单步最大输出Token retry_on_parse_error: 3 # 模型输出解析失败重试次数 model: provider: deepseek # 模型供应商 model_name: deepseek-chat # 模型名请以实际控制台为准 temperature: 0 # 尽量降低随机性 context: strategy: sliding_window max_messages: 40 compress_threshold: 8000 # 超过阈值触发摘要压缩 max_tool_result_len: 2000 # 工具结果截断长度 security: allowed_commands: [ls, cat, grep, git diff, pwd] require_human_approval: - file_delete - git_push - deploy sandbox: workdir observability: trace_exporter: otlp log_level: info cost_alert_threshold: 5这个配置反映了几条设计原则Agent模式选择、上下文策略、安全白名单和可观测性都是独立配置项便于不同团队按需调整高风险工具被明确标注为需要人工审批日志和成本告警从一开始就纳入配置。7. 常见问题与排查思路问题现象可能原因排查方式解决方案Agent陷入工具调用死循环模型反复调用同一工具未判断结果是否有效查看Trace中工具调用序列和步数统计设置最大步数要求模型在结果异常时改变策略对重复调用做熔断上下文很快被撑爆工具返回结果过大未截断就写入历史检查上下文管理器日志确认工具结果长度对工具结果设置最大长度只回填摘要或关键字段模型输出无法解析为JSON未开启JSON Mode或提示词没有给出输出Schema查看原始输出内容与解析报错位置开启JSON Mode提示词中给出严格Schema增加解析失败重试模型反复传错工具参数工具Schema不清晰或模型对参数类型理解有误检查工具描述和参数Schema是否明确增加参数类型约束和枚举值说明用函数调用协议代替自由文本JSON危险命令被误执行权限配置过于宽松未做白名单校验查看审计日志中的命令和授权记录默认拒绝未知命令高风险操作加人工审批任务中途失败且无法恢复失败时直接抛异常没有把错误回传给模型检查异常处理逻辑和回传格式把异常信息格式化为observation消息让模型自行修正设置重试与熔断Token成本快速上涨循环步数过多或上下文长期处于高水位查看每步Token消耗统计和成本告警设置单任务成本上限优先使用滑动窗口和摘要压缩同一工具连续失败后仍然重试缺少重试策略和熔断机制检查重试逻辑中是否有失败计数同一工具连续失败N次后暂停使用并让模型换方案排查Harness问题时要记住一个顺序先看Trace确认问题发生在哪个环节再看模型原始输出和工具执行结果最后检查配置项是否合理。不要一上来就怀疑模型能力很多问题出在Harness对模型输出的处理方式上。8. 最佳实践与工程建议8.1 先跑通最小闭环再上复杂度很多团队一开始就设计复杂的Multi-Agent架构结果连单Agent都还不稳定。更合理的路线是先用一个agent loop加上两三个工具跑通最小闭环验证核心思路再逐步加入上下文管理、权限控制、可观测性等能力最后才考虑多Agent协作和事件驱动架构。每个阶段都要有明确的验证指标比如任务成功率、平均步数、Token成本。8.2 工具要少而精描述要清晰工具列表不是越长越好。模型在多个工具之间做选择时工具描述不清晰会直接影响准确率。建议控制工具数量每个工具只做单一职责描述中写清楚“这个工具是干什么的、什么时候用、参数含义是什么”。上线新工具前先在测试集上验证模型能否正确选择并传参再用到生产环境。8.3 安全默认拒绝权限最小化这是最不能妥协的一条。Agent应该默认没有权限而不是默认有权限。命令执行要基于白名单文件系统访问要限定工作目录高风险操作要人工审批。即便在本地开发环境也不建议直接给Agent全部Shell权限。每一次权限调整都要记录原因定期审查授权范围。8.4 Harness本身要有自动化测试Harness是基础设施它的稳定性直接影响所有Agent任务。建议为Harness建立测试集包括正常任务的成功率测试、模型返回非法JSON的解析测试、工具抛异常的错误恢复测试、上下文超过阈值的压缩测试、权限拦截的安全测试。这些测试能防止你在迭代中引入回归问题。Harness的每次改动都应该像普通后端服务一样走代码评审和发布流程。8.5 架构模式选型要贴合场景Harness内部可以有多种架构选择。分层式架构把模型层、工具层、编排层分离适合团队分工明确的场景事件驱动架构让工具结果、超时、审批等以事件形式异步流转适合高并发或长任务场景黑板模型让多个Agent共享一块上下文黑板适合需要协作的复杂任务。没有银弹关键是根据任务特点选择并保持架构的可演进性。8.6 与CI/CD流程结合Agent生成的代码最终要进入交付链路。更稳妥的做法是让Agent负责编码和生成Diff把构建、测试、部署留在传统CI/CD平台里执行。这样既利用了Agent的代码生成效率又保留了正式交付流程的审批、灰度、回滚能力。两者不是替代关系而是各司其职。9. 面试高频问题与答题思路9.1 什么是Agent Harness它和普通模型调用有什么区别答题思路先说本质Harness是承载Agent运行的运行时外壳负责Agent Loop、工具调用、上下文管理、安全控制和可观测性。普通模型调用是一次性的“输入输出”模型无状态、只返回文本Agent Harness则把模型输出解析为动作执行动作后把结果回传给模型形成多轮闭环。可以再补充一句判断模型决定智能上限Harness决定工程下限。9.2 如何设计一个稳定、可控的Agent Loop答题思路从参数和机制两个维度回答。参数上设置最大步数、单步超时、连续失败阈值机制上要求模型输出结构化JSON或使用函数调用协议解析失败时重试工具异常时捕获并回传错误信息每一步写入日志。核心目标是防止Agent在错误路径上无限循环并保证任务全程可追踪、可回滚。9.3 上下文窗口有限如何管理长任务答题思路回答分层策略。最近几轮保留完整消息较早对话用模型生成摘要事实性数据存入外部记忆或向量数据库按需检索。同时要控制工具返回结果的长度在写入历史前截断。还可以提到压缩触发阈值例如Token达到窗口70%时触发摘要。9.4 工具调用出错怎么办答题思路不要把异常直接抛出让任务失败。先捕获异常把错误信息格式化为observation消息回传给模型让模型基于错误决定下一步同时设置重试次数和熔断机制同一工具连续失败N次后暂停使用。这里能让面试官看到你对异常路径的考虑。9.5 如何保证Agent执行安全答题思路强调“默认拒绝”和“最小权限”。命令执行用白名单文件访问限定工作目录高风险操作如删除、推送、部署必须人工审批所有操作写审计日志。可以补充容器沙箱和OpenTelemetry追踪说明你考虑过隔离和可追溯。9.6 如何评估一个Harness的好坏答题思路从任务成功率、平均步数、Token成本、工具调用准确率、失败恢复能力、可观测性和安全审计完整性等维度回答。还可以提到A/B测试和回归测试集说明你会用数据驱动方式迭代Harness而不是凭感觉调参。9.7 ReAct和Plan-and-Execute模式怎么选答题思路ReAct是“边思考边行动”灵活性强适合探索型任务但Token消耗较高Plan-and-Execute是“先规划后执行”可控性好适合流程稳定、步骤明确的任务。实际生产中常见混合用法先让模型规划子任务每个子任务内用类似ReAct的方式执行。回答时结合具体场景会更有说服力。9.8 为什么说架构模式会影响Harness设计答题思路可以对比三种模式。分层式架构适合职责清晰、团队协作的工程化场景事件驱动架构适合长任务、异步协作和故障隔离黑板模型适合多Agent共享上下文的复杂协作场景。关键结论是Harness不是一次性写死的框架它需要根据任务复杂度、团队规模和演进阶段持续调整。面试官问Harness本质是想确认你有没有真正构建过Agent系统而不只是会调模型API。如果你能清晰解释Agent Loop、上下文管理、安全设计和可观测性并且能随手写出关键代码就已经具备很强的说服力。建议你把第5章的最小Harness自己实现一遍再尝试加入权限拦截和上下文截断这比背十道面试题更有用。