1. 什么是 Harness Engineering从“胶水代码”到系统性工程范式的跃迁很多人第一次看到“Harness Engineering”这个词下意识会把它翻译成“挽具工程”或者“马具工程”甚至怀疑是不是某个冷门机械设计分支。其实这完全是个美丽的误会——这里的harness不是名词“挽具”而是动词“驾驭、控制、整合”的意思。Harness Engineering 的本质不是造一个物理上的“套子”而是构建一套可复用、可验证、可演进的智能体Agent集成与调度基础设施。它解决的是当下 AI 应用开发中最痛的一个现实问题当你的项目里同时跑着 LangChain 的 ReAct Agent、LangGraph 的状态机流、自研的工具调用路由、外部 API 封装层、以及多个 LLM 模型切换逻辑时这些模块之间像一盘散沙靠临时写的 if-else、硬编码的 URL、手写 JSON Schema 去拼接结果就是改一个 prompt三个地方要同步换一个模型四个服务要重启加一个新工具整个链路要重测半天。我最早在 2023 年底接手一个客户项目时就深有体会。他们用 LangChain 写了一个客服知识库问答 Agent运行得很稳后来业务方说“能不能再加个订单查询功能”工程师随手加了个 SQL 工具调用但没做输入校验再后来要接入内部审批流又硬塞进一个 HTTP 调用节点。三个月后这个“单体 Agent”已经膨胀到 800 多行 Python没有单元测试没有可观测性埋点连日志都分不清是哪个工具抛的异常。上线后只要用户问一句“我上个月的订单为什么没发货”整个链路就卡死在数据库连接超时上而错误日志只显示 “Tool execution failed”根本看不出是哪个工具、哪条 SQL、哪个连接池配置错了。这就是典型的“无 Harness”状态每个 Agent 都是孤岛每次扩展都是野蛮生长每次维护都是刮骨疗毒。Harness Engineering 正是为终结这种混乱而生。它不替代 LangChain 或 LangGraph而是站在它们之上定义一套接口契约、生命周期管理、错误传播机制和可观测性标准。你可以把它理解成 Agent 世界的“Kubernetes”LangChain 是一个个 Docker 容器封装了具体能力LangGraph 是容器编排脚本定义执行顺序而 Harness Engineering 就是整个集群的调度器、健康检查探针、日志聚合中心和资源配额控制器。它让“加一个新工具”变成注册一个符合ToolInterface协议的类让“切模型”变成修改一个环境变量让“查故障”变成打开 Grafana 看agent_execution_duration_seconds这个指标曲线。这不是炫技而是把 AI 工程从“手工作坊”推进到“现代工厂”的必经之路。它背后真正驱动的是 OpenAI API 的标准化响应格式{ id: ..., choices: [ { message: { role: assistant, content: ... } } ] }、LangChain 提供的抽象基类BaseTool,BaseLLM、以及开发者对稳定性和可维护性的集体觉醒。所以当你看到热搜里反复出现 “harness engineering 如何落地”“harness engineering 最佳实践”本质上大家问的不是“怎么写代码”而是“怎么建立一套让团队能长期协作、持续交付的工程纪律”。2. 范式一协议驱动型 Harness —— 一切皆接口契约即法律协议驱动型 Harness 是五大范式中最基础、也最常被低估的一种。它的核心信条只有一条任何参与 Agent 执行链路的组件必须严格遵守预定义的输入/输出协议否则不予接入。这听起来像废话但现实中 90% 的集成失败根源都在协议层面的“差不多就行”。比如一个 LangChain Tool 返回的是{result: OK}而另一个自研工具返回的是{data: {status: success}}下游的 Router 根本无法统一解析只能写一堆if result in resp else if data in resp的脏代码。协议驱动型 Harness 就是要用“法律”来终结这种混乱。它的实现骨架非常清晰由三块基石构成统一请求协议Request Contract、统一响应协议Response Contract和协议验证中间件Contract Validator。我们以一个典型的SearchTool为例来拆解。在协议驱动范式下它不能随便定义自己的输入字段。它的input_schema必须继承自一个全局的BaseToolInputPydantic 模型from pydantic import BaseModel, Field from typing import Optional, Dict, Any class BaseToolInput(BaseModel): 所有工具输入的基类强制包含 trace_id 和 timeout trace_id: str Field(..., description全链路追踪 ID用于日志关联) timeout: float Field(30.0, description最大执行时间单位秒) class SearchToolInput(BaseToolInput): query: str Field(..., description用户搜索关键词) max_results: int Field(5, ge1, le100, description最多返回结果数) class SearchToolOutput(BaseModel): 所有工具输出的基类强制包含 status 和 error status: str Field(..., pattern^(success|failure)$, description执行状态) error: Optional[str] Field(None, description错误信息仅在 statusfailure 时存在) data: Dict[str, Any] Field(default_factorydict, description业务数据结构由具体工具定义)看到这里你可能会问为什么非得加trace_id和timeout因为这是 Harness 的“宪法条款”。trace_id是为了打通从用户请求、LLM 调用、工具执行到最终响应的完整链路没有它你就无法在日志里把一次用户提问的所有相关日志串起来timeout则是为了防止某个工具比如一个慢 SQL 查询拖垮整个 Agent 流程。这两个字段不是可选项而是强制要求任何试图绕过它们的工具在注册阶段就会被Contract Validator拒绝。响应协议同样铁面无私。无论你底层用的是 Elasticsearch、Google Custom Search 还是自己爬虫最终返回给 Router 的必须是SearchToolOutput的实例。Router 只认这个结构它会检查status字段如果是success就提取data里的results列表喂给 LLM如果是failure就直接触发 fallback 逻辑比如返回“抱歉暂时无法查询请稍后再试”而不会去尝试解析一个可能不存在的error_message字段。这种“强契约”带来的好处是惊人的。去年我帮一家电商公司重构他们的商品推荐 Agent他们原来有 7 个不同团队开发的工具价格查询、库存检查、竞品分析、用户画像、促销规则、物流时效、评论摘要每个工具的输入输出格式都自成一派。我们花了两周时间用协议驱动范式统一了所有接口。结果是新增一个“环保认证查询”工具只需要按模板写好Input和Output模型注册进 Harness整个链路就能自动识别并调用前后端都不用改一行代码。上线后平均故障定位时间MTTR从原来的 47 分钟降到了 3 分钟以内因为所有日志都带着同一个trace_id运维同学在 Kibana 里搜一下就全出来了。提示协议驱动范式最大的陷阱是把“协议”做成“摆设”。我见过太多团队定义了一堆漂亮的 Pydantic 模型但在实际调用时用dict直接构造返回值绕过模型的字段校验和类型转换。这等于在宪法上签字转身就违法。务必在Contract Validator中加入运行时校验例如在工具执行完毕后强制调用SearchToolOutput.model_validate(response_dict)一旦失败就抛出ValidationError并记录告警。这才是真正的“契约即法律”。3. 范式二状态机驱动型 Harness —— 让 Agent 的“思考过程”变得可读、可调试、可回滚如果你觉得协议驱动型 Harness 解决的是“组件怎么说话”的问题那么状态机驱动型 Harness 解决的就是“组件什么时候说话、为什么这么说”的问题。它把整个 Agent 的执行流程从一个黑盒的、不可预测的函数调用链变成一个白盒的、状态明确的有限状态机FSM。每一个状态State代表 Agent 当前所处的决策点或执行阶段每一次状态转移Transition都由一个明确定义的事件Event触发并伴随着可审计的日志和可观测的指标。这正是 LangGraph 所推崇的范式但它在 Harness Engineering 的语境下被提升到了基础设施层。我们以一个常见的“多步骤客服工单处理 Agent”为例。传统做法可能是LLM 输出一个 JSON里面写着next_action: query_order然后代码里if next_action query_order就去调用订单查询工具。问题在于这个next_action是 LLM 自由发挥的字符串它可能今天是query_order明天微调模型后就变成了get_order_info整个逻辑就崩了。状态机驱动型 Harness 的做法是预先定义好所有合法状态和转移规则让 LLM 的输出变成对这个状态图的一次“选择”。首先我们定义状态图from enum import Enum from typing import List, Dict, Any class AgentState(str, Enum): INIT init # 初始状态等待用户输入 UNDERSTAND understand # 理解用户意图可能需要澄清 QUERY_ORDER query_order # 查询订单详情 CHECK_STOCK check_stock # 查询库存 GENERATE_RESPONSE generate_response # 生成最终回复 ESCALATE escalate # 升级至人工 class StateTransitionRule: def __init__(self, from_state: AgentState, event: str, to_state: AgentState, condition: str None): self.from_state from_state self.event event self.to_state to_state self.condition condition # 可选的布尔表达式如 order_status shipped # 预定义所有合法转移 TRANSITIONS [ StateTransitionRule(AgentState.INIT, user_input_received, AgentState.UNDERSTAND), StateTransitionRule(AgentState.UNDERSTAND, intent_classified_as_order_query, AgentState.QUERY_ORDER), StateTransitionRule(AgentState.QUERY_ORDER, order_found, AgentState.CHECK_STOCK), StateTransitionRule(AgentState.QUERY_ORDER, order_not_found, AgentState.ESCALATE), StateTransitionRule(AgentState.CHECK_STOCK, in_stock, AgentState.GENERATE_RESPONSE), StateTransitionRule(AgentState.CHECK_STOCK, out_of_stock, AgentState.GENERATE_RESPONSE), ]关键来了Harness 不会让 LLM 自由输出字符串。它会把当前状态比如INIT和所有从该状态出发的合法event比如[user_input_received]一起构造成一个结构化提示Structured Prompt发送给 LLM。例如你是一个客服工单处理 Agent。当前状态是INIT。 你刚刚收到了用户的输入“我的订单 123456 还没发货怎么回事” 请从以下合法事件中选择一个最合适的事件来描述你接下来要做的动作 - user_input_received (表示已收到并理解用户输入) - need_clarification (表示需要用户进一步澄清) - invalid_input (表示用户输入无效) 请只输出事件名称不要有任何其他文字。LLM 的输出被严格限制在[user_input_received, need_clarification, invalid_input]这个集合内。Harness 收到输出后会查找TRANSITIONS表找到from_stateINIT且eventuser_input_received的那条规则确认to_stateUNDERSTAND然后将 Agent 的状态更新为UNDERSTAND并记录一条日志“State transition: INIT - UNDERSTAND via user_input_received”。整个过程就像交通信号灯红灯停、绿灯行没有模糊地带。这种设计带来的最大价值是可调试性。当一个工单处理失败时你不再需要去翻几百行日志猜 LLM 在想什么。你只需要看状态流转日志就能一眼看出问题出在哪一步。比如日志显示QUERY_ORDER - ESCALATE说明订单没查到那就立刻去查订单服务是否宕机如果日志显示CHECK_STOCK - GENERATE_RESPONSE但生成的回复是错的那问题就出在CHECK_STOCK工具的返回数据上而不是 LLM 的推理逻辑。更妙的是它支持状态回滚。假设GENERATE_RESPONSE状态下LLM 生成的回复被内容安全策略拦截了Harness 可以直接把状态切回CHECK_STOCK并带上一个retry_count1的上下文让 LLM 重新生成而不是从头开始整个流程。这在处理高价值、高风险的业务场景如金融交易确认时是至关重要的容错能力。注意状态机驱动范式最容易犯的错误是把状态图设计得过于复杂导致TRANSITIONS表爆炸式增长难以维护。我的经验是一个健康的 Agent 状态图状态数应控制在 5-8 个以内每个状态的出度向外的转移数不超过 3。如果发现你需要定义 15 个状态那大概率是你把“业务逻辑”和“Agent 控制流”混在一起了。应该把复杂的业务判断比如“根据用户等级、订单金额、历史投诉次数综合判定是否升级”下沉到一个独立的BusinessRuleEngine工具里让它输出一个简单的{should_escalate: true}然后 Harness 只根据这个布尔值做ESCALATE或GENERATE_RESPONSE的二元选择。让状态机保持简洁让业务逻辑保持灵活。4. 范式三路由驱动型 Harness —— 动态决策引擎让 Agent 懂得“因地制宜”路由驱动型 Harness 是五大范式中最具“智能感”的一种。如果说协议驱动关注“怎么说”状态机驱动关注“何时说”那么路由驱动关注的就是“对谁说”和“说什么”。它把 Agent 的执行链路从一条固定的、线性的流水线变成一张动态的、可编程的决策网络。其核心是一个中央路由引擎Router Engine它接收一个统一的ExecutionRequest根据请求的上下文Context、元数据Metadata和预设的路由策略Routing Policy实时决定将请求分发给哪个具体的 Agent 实例、哪个 LLM 模型、甚至哪个物理服务器集群。这正是热搜词中反复出现的 “需要路由服务才能正常使用”“请先启动路由” 所指的核心组件。路由的决策依据远不止于简单的 URL 匹配。一个成熟的路由引擎会综合考量至少五个维度维度示例决策影响语义意图Semantic Intent用户输入“帮我写一封辞职信” vs “帮我写一封表扬信”路由到不同的 Prompt 模板库和风格微调模型业务 SLAService Level Agreement请求来自 VIP 客户SLA 要求 2s 响应路由到专用的、低延迟的 GPU 集群跳过耗时的缓存校验数据敏感性Data Sensitivity输入中包含身份证号、银行卡号路由到部署在私有云、符合 GDPR 的模型实例禁止日志记录原始输入模型能力Model Capability请求需要处理 100 页 PDF 文档路由到支持长上下文128K tokens的 Claude 3 模型而非仅支持 4K 的 GPT-3.5成本预算Cost Budget请求来自免费试用用户预算为 $0.01路由到低成本的开源模型如 Qwen2-7B而非昂贵的 GPT-4实现这样一个多维路由引擎关键在于策略即代码Policy as Code。我们不会在配置文件里写一堆 if-else而是用一种声明式的、可版本控制的策略语言来定义。下面是一个基于 Python 的简化版策略 DSL 示例# routing_policy.py from harness.router import RoutePolicy, Rule, Condition, Action # 定义一个名为 vip_fast_path 的路由策略 vip_fast_path RoutePolicy( namevip_fast_path, description为 VIP 客户提供超低延迟路径, # 规则列表按顺序匹配 rules[ # 规则1如果用户是 VIP 且请求是文本生成类 Rule( conditionCondition( # 条件用户角色是 VIP AND 意图是 text_generation and_[ user.role vip, intent.type text_generation ] ), actionAction( # 动作路由到 fast-gpu-cluster使用 gpt-4-turbo 模型设置超时为 1.5s targetfast-gpu-cluster, modelgpt-4-turbo, timeout1.5, # 强制开启 tracing 和 metrics 上报 enable_tracingTrue, enable_metricsTrue ) ), # 规则2如果输入包含敏感 PII 数据 Rule( conditionCondition( or_[pii_detected_in_input] ), actionAction( targetprivate-cloud-cluster, modelclaude-3-haiku, # 禁用所有日志记录原始输入 log_inputFalse ) ), # 默认规则兜底到通用集群 Rule( conditionCondition(alwaysTrue), actionAction( targetgeneral-cluster, modelqwen2-7b ) ) ] ) # 将策略注册到路由引擎 router.register_policy(vip_fast_path)这个策略文件可以像普通代码一样提交到 Git 仓库进行 Code Review和业务需求变更一起发布。当市场部宣布下个月起所有 VIP 客户都将享受专属服务时运维同学只需要修改vip_fast_path策略中的timeout字段然后git push整个路由逻辑就完成了灰度发布。这比登录到服务器手动改 Nginx 配置或者在 LangChain 的LLMChain里硬编码if user.vip: llm GPT4Turbo()要可靠、可追溯、可协作得多。我在一个跨境支付公司的项目中亲眼见证了路由驱动范式的威力。他们有面向欧美、东南亚、中东三个大区的客服 Agent每个区的法规、语言习惯、常用支付方式都不同。以前的做法是部署三套完全独立的 LangChain 应用代码重复率高达 70%维护成本极高。采用路由驱动后我们只维护一套核心 Harness 代码通过一个region_routing_policy根据用户 IP 归属地、请求头中的Accept-Language和X-Country-Code动态路由到对应的区域专属 Prompt 模板和本地化模型。当需要为中东区增加阿拉伯语支持时我们只新增了一个arabic_prompt_template和一条路由规则整个系统无需重启零 downtime。这不仅是技术升级更是组织效能的革命——它让“快速响应区域化需求”从一个需要跨部门协调的项目变成了一个工程师可以独立完成的 PR。5. 范式四可观测性驱动型 Harness —— 把 Agent 的“黑盒”变成透明的“玻璃盒子”可观测性驱动型 Harness 是五大范式中最具“运维视角”的一种。它不直接参与 Agent 的逻辑决策却为所有其他范式提供了生存的土壤。它的核心信条是一个无法被观测的 Agent就是一个注定会失控的 Agent。在传统 Web 服务中我们有 Prometheus 的http_request_duration_seconds有 ELK 的 structured logs有 Jaeger 的分布式 trace。但当服务主体变成一个由 LLM 驱动、行为高度不确定的 Agent 时这些指标就远远不够了。可观测性驱动型 Harness 的任务就是定义并采集那些专属于 AI 系统的、更高维度的“生命体征”。它围绕三个支柱构建追踪Tracing、指标Metrics和日志Logging但每一项都针对 Agent 的特性做了深度定制。首先是Tracing。一个标准的 OpenTelemetry trace在 Agent 场景下会变得异常复杂。一次用户提问可能触发1) LLM 调用llm.invoke2) 工具 A 调用tool_a.invoke3) 工具 B 调用tool_b.invoke4) LLM 第二次调用llm.invoke5) 最终响应生成。这五个 span 之间不仅有父子关系还有因果关系Cause-Effect。比如tool_a.invoke的输出是llm.invoke第二次的输入的一部分。可观测性驱动型 Harness 会在每个 span 的attributes中注入这些语义化的上下文{ name: llm.invoke, attributes: { llm.model_name: gpt-4-turbo, llm.input_tokens: 1250, llm.output_tokens: 320, llm.temperature: 0.7, llm.top_p: 1.0, agent.state: query_order, agent.trace_id: abc123, agent.parent_span_id: span_xyz, // 指向触发本次调用的 tool_a.invoke llm.prompt_hash: sha256:abcd1234... // 用于识别重复的 prompt 模板 } }其次是Metrics。除了常规的http_requests_total我们需要一系列 AI 特有的黄金指标Golden Signals指标名类型说明业务意义agent_execution_duration_secondsHistogram整个 Agent 执行耗时SLA 达标率的核心依据llm_token_usage_totalCounterLLM 消耗的总 token 数成本核算的直接来源tool_invocation_totalCounter各工具被调用的总次数识别高频、低效工具的关键agent_fallback_rateGaugeFallback降级发生的比率衡量 Agent 可靠性的晴雨表prompt_cache_hit_rateGaugePrompt 模板缓存命中率优化性能的重要抓手最后是Logging。Agent 的日志绝不能是INFO:root:Tool executed successfully这样的废话。它必须是结构化、带上下文、可关联的。Harness 会强制所有组件LLM Wrapper、Tool Executor、Router在日志中注入trace_id、state、tool_name、model_name等字段。这样当我们在 Grafana 里看到agent_fallback_rate突然飙升到 15%就可以立刻在 Loki 里搜索trace_id找到所有相关的日志精准定位到是哪个工具比如payment_gateway_tool在特定时间段内因为ConnectionTimeout错误导致了连锁的 fallback。这套可观测性体系的价值在于它把“玄学”变成了“科学”。过去当老板问“为什么上个月的用户满意度下降了 5%”工程师只能凭感觉回答“可能是模型变差了”或者“可能是数据有问题”。现在我们可以拿出一份仪表盘agent_fallback_rate从 2% 上升到 15%tool_invocation_total{tool_nameinventory_check}下降了 40%llm_token_usage_total{model_namegpt-4-turbo}却上升了 25%……结论呼之欲出库存查询工具大面积超时导致 Agent 频繁 fallback 到更贵的 GPT-4 模型去“猜测”答案既增加了成本又降低了准确性。所有的决策都有数据支撑所有的优化都有目标指向。这不再是工程师的个人直觉而是整个团队共享的、客观的、可行动的洞察。提示构建可观测性驱动型 Harness最大的误区是“为了监控而监控”堆砌大量华而不实的指标。我的建议是从最痛的三个问题开始1) 我们最常花时间排查的故障是什么比如“响应慢”→ 就重点监控agent_execution_duration_seconds2) 我们最关心的成本是什么比如 LLM token→ 就重点监控llm_token_usage_total3) 我们最怕的线上事故是什么比如“大规模 fallback”→ 就重点监控agent_fallback_rate。先用这三个指标搭起骨架再根据实际运营情况逐步添加血肉。一个能解决实际问题的精简仪表盘远胜于一个好看但无用的“监控大屏”。6. 范式五反脆弱驱动型 Harness —— 让 Agent 在混沌中自我进化反脆弱驱动型 Harness 是五大范式中最高阶、也最具哲学意味的一种。它超越了“让系统不出错”健壮性和“出错后能恢复”韧性追求的是“从错误、压力和不确定性中获益变得比之前更强”。这正是纳西姆·塔勒布提出的“反脆弱性”Antifragility概念在 AI 工程领域的落地。在 Agent 开发中“脆弱”的典型表现是模型微调后原本稳定的工具调用链突然崩溃上游 API 返回格式发生微小变更比如把user_id字段名改成uid整个 Agent 就无法解析甚至只是 LLM 的温度temperature参数从 0.5 调到 0.6就导致生成的 JSON 格式失效。反脆弱驱动型 Harness 的目标就是让系统不仅能扛住这些“混沌”还能从中学习、适应、进化。它的实现依赖于一个闭环的“混沌-反馈-进化”Chaos-Feedback-Evolution机制。这个机制由三个核心组件构成混沌注入器Chaos Injector一个主动制造可控混乱的工具。它不是为了搞破坏而是为了暴露系统的弱点。它可以模拟API 故障随机让某个工具的 HTTP 调用返回 503 Service Unavailable。数据污染在工具返回的 JSON 中随机篡改一个字段的类型把int改成string或值把status: success改成status: succ3ss。LLM 行为漂移在 LLM 的输出中随机插入一个语法错误比如少一个逗号或者让其输出一个格式完全错误的 JSON。反馈收集器Feedback Collector一个被动监听系统“痛苦”的传感器。它不只监听错误日志更关注那些“软性失败”Soft Failures格式校验失败Contract Validator发现工具输出不符合ToolOutput协议。语义解析失败Router 无法从 LLM 的 JSON 输出中提取出有效的next_action。置信度不足LLM 返回的choices[0].finish_reason是length被截断或者logprobs显示最高概率的 token 置信度低于阈值。进化引擎Evolution Engine一个基于反馈数据自动优化系统的“大脑”。它的工作流程是聚类分析将所有反馈事件按模式聚类。例如发现 80% 的format_validation_failure都发生在SearchTool的data.results字段且错误类型都是list期望但得到了None。根因推断结合混沌注入的记录推断出根因上游搜索引擎在无结果时返回了{results: null}而SearchTool的代码没有做None值的防御性处理。自动化修复生成并应用一个修复补丁。例如自动在SearchTool的invoke方法中插入一行if response.get(results) is None: response[results] []。A/B 测试将修复后的SearchTool作为新版本与旧版本并行运行一小部分流量对比format_validation_failure率确认修复有效后再全量发布。这个闭环让 Harness 具备了“自我免疫”的能力。它不再是一个静态的、需要工程师手动打补丁的框架而是一个能随着环境变化而持续进化的有机体。我在一个新闻摘要 Agent 项目中就部署了这样的反脆弱机制。我们发现每当主流新闻网站改版其 HTML 结构发生变化时我们的爬虫工具就会大量失败。传统的做法是等运维告警然后工程师熬夜改 XPath 表达式。而反脆弱驱动型 Harness 的做法是每天凌晨 3 点混沌注入器会自动抓取 10 个主流网站的最新首页将其 HTML 作为“变异样本”注入到爬虫工具的测试流程中。反馈收集器会捕获所有解析失败的案例并上传到一个中央知识库。进化引擎会分析这些失败案例发现其中 70% 都是因为article标签的 class 名从post-content变成了news-article。于是它自动生成一个更新后的 CSS 选择器article.post-content, article.news-article并通过 CI/CD 流水线自动部署。整个过程无人值守系统在网站改版的当天就完成了自我适配。注意反脆弱驱动型 Harness 是一把双刃剑。它的强大源于其自动化程度它的危险也源于此。因此必须设置严格的“安全网”Safety Net。我的实践是1) 所有由进化引擎生成的代码补丁都必须经过一个“人类审核门禁”Human-in-the-Loop Gate只有工程师点击“批准”才会进入 CI 流水线2) 每次自动修复都必须伴随一个完整的、可回滚的 Git CommitCommit Message 清晰注明“[AUTO] Fix format validation for SearchTool due to upstream API change on 2024-05-20”3) 进化引擎本身也要被纳入可观测性驱动型 Harness 的监控范围确保它的决策过程也是透明、可审计的。技术的终极目的不是取代人而是让人从重复劳动中解放出来去思考更本质的问题。
