智能体安全带Agent Harness：从概念到工程实践详解

智能体安全带Agent Harness是近两年智能体开发里出现频率最高的词之一。很多人把它当成又一个包装大模型 API 的框架也有人把它和 Agent 框架、Skill、Tool 混在一起讨论。简单说Agent 负责“决定下一步做什么”Agent Harness 负责“让这一步真正安全、可监督、可控制地被执行”。它不是一层可有可无的封装而是连接大模型推理与外部工具执行之间的一套运行控制和风险控制机制。本文会先拆清概念把智能体、智能体框架、Skill、Tool 与 Agent Harness 的区别讲明白然后顺着一次真实调用链路看 Harness 在哪个环节介入接着给一个最小可运行的代码雏形再讲清生产环境里 Harness 必须控制好的五个边界、常见故障排查链路和落地清单。适合正在搭建智能体项目、做智能体平台选型或者想把这些概念讲清楚再动手写代码的开发者和技术负责人。1. 先厘清智能体、智能体框架和智能体安全带之间的关系1.1 Agent 是“思考者”Harness 是“行动支撑层”大模型本身只是一个文本生成模型它并不知道自己可以调用接口、查询数据库或操作文件。要让大模型从“会聊天”变成“会做事”通常要给它套一层 Agent 循环模型根据用户输入和已有信息输出一个意图系统执行这个意图再把执行结果回传给模型让模型继续推理。这个过程就是观察、思考、行动、再观察。但这个循环里有一个关键问题模型只能输出“想调用什么工具”的文本或结构化 JSON真正执行工具的还是外部代码。谁负责解释模型输出谁负责校验工具参数谁负责注入凭证谁负责限制调用次数谁负责记录调用日志这些工作如果散落在业务代码里会让每个调用点各自为政权限控制很难统一。Agent Harness 就是把这些职责收敛起来的执行与管控层。可以把它理解为智能体的“行动支撑层”。Agent 是思考者Harness 是行动者背后的工作台和安全带。它至少解决三个问题运行问题给 Agent 提供可执行工具、记忆和会话管理能力。控制问题限制 Agent 能调用什么工具、能访问什么资源、能跑多久。监督问题记录 Agent 每一步操作方便排错和审计。举一个最小例子。模型收到“查询订单 10086 的状态”后可能输出类似{action: query_order, order_id: 10086}的结构。如果没有 Harness这条输出只是一段文本什么都不会发生。有了 Harness系统会在解析它之后查找名为query_order的工具校验参数格式检查该工具是否在白名单中再真正发起查询。查询结果会写回上下文模型才能继续生成最终回答。1.2 Harness 最容易与三个邻近概念混淆在实际讨论中经常有人把 Agent Framework、Skill、Tool 和 Agent Harness 画成同一个东西。它们确实相关但职责粒度不同。先用表格区分概念关注点典型形态容易出现的误区Agent对话策略和推理循环决定下一步做什么提示词、循环逻辑、工具调用策略以为 Agent 本身自带执行能力Skill能力的描述方式说明某个能力“会什么”技能说明、输入输出 schema以为声明了 Skill 就等于能执行Tool具体执行体说明“怎么做”函数、HTTP 接口、SDK 封装以为封装了 Tool 就等于安全可控Agent Framework连接模型、记忆、工具和调用链的集成框架LangChain、各类 Agent 框架以为用了框架就自动有了完整治理能力Agent Harness智能体的运行环境和控制边界执行器、权限策略、资源限制、审计日志以为 Harness 只是模型调用的又一层封装Harness 和 Framework 的区别最容易被忽略。Framework 解决“组件之间怎么衔接”它更多是集成层Harness 解决“组件在什么条件下运行”它更多是运行时治理层。一个不引入框架的纯代码项目只要设计好执行循环、权限检查和日志就已经实现了最小 Harness而一个重度使用框架的项目如果只按框架默认方式拼装工具没有超时和权限控制仍然缺少 Agent Harness 该承担的那部分能力。Harness 和 Skill/Tool 的区别也更清楚。Skill 是能力说明书Tool 是能力执行器Harness 是承载并限制执行器的地方。工具可以不做任何安全检查Harness 必须在调用前和调用后都施加约束。同一套词汇里还会出现“Agent Claw工具抓手”的说法它更多描述模型对工具的抓取和直接操作能力并不是一个完整执行运行时。Agent Harness 则把这种抓取动作放进可受控的执行环境因此不能用“能给模型挂工具”来替代“给模型套安全带”。一个常见误区是给 Agent 配置满了工具就认为项目已经“安全”。实际上工具数量越多模型越容易选错、越容易触发危险操作。没有 Harness 的 Agent 就像只给模型发放了全部钥匙却没有走廊、门禁和监控。2. 从一次 Agent 调用看 Harness 在链路里的位置2.1 一次完整的 Agent 调用会经过哪些环节要理解 Harness 的职责最好把它放进一次完整调用链路里看。一次典型的 Agent 请求会按下面这个顺序经过多个环节接收用户输入。加载会话历史检查上下文窗口。组装系统提示包括 Agent 身份、工具描述、安全说明。调用大模型生成回复。解析模型输出判断是最终回答还是工具调用请求。如果是工具调用请求校验动作名称和参数。检查该动作是否被允许、凭证是否可用。执行工具并记录开始时间、结束时间和结果。对工具返回结果做截断或脱敏回填到上下文中。将本轮消息和工具执行记录保存。再次调用模型继续循环直到模型给出最终回答。HArness 不负责“教模型怎么思考”但它在第 2、3、6、7、8、9、10 环节都承担关键控制。第 3 步控制模型能看见哪些工具第 6 步控制参数合法性第 7 步控制权限边界第 8 步控制超时和并发第 9 步控制上下文污染第 10 步控制状态持久化。2.2 用一段伪代码表达 Harness 的核心循环下面这段 Python 伪代码展示了 Harness 在一个最小 Agent 循环里所处的位置。它不是某个框架的完整实现只用于说明职责边界。def run_agent(harness, user_input): session harness.create_session() while not session.finished: messages harness.build_messages(session, user_input) response harness.llm_client.chat(messages) plan harness.parse_plan(response) if plan.is_final_answer: return plan.final_answer allowed, reason harness.security_policy.check(plan.action, plan.params) if not allowed: session.add_feedback(f拒绝执行 {plan.action}原因{reason}) continue result harness.executor.run( actionplan.action, paramsplan.params, timeoutharness.config.timeout_seconds, ) harness.memory.append_tool_result(plan.action, result) harness.observability.record( stepsession.step, actionplan.action, paramsplan.params, result_summaryresult.summary(), ) session.step 1这段伪代码里的security_policy、executor、memory、observability就是 Harness 的四个最小模块。executor 负责真正调用工具security_policy 负责做执行前检查memory 负责维护会话上下文observability 负责记录每一步操作。在实际项目中harness.executor.run不会是简单的函数调用。它通常要封装 HTTP 超时、连接池、重试策略、凭证注入和返回结果裁剪。parse_plan也要处理模型输出不合法、输出 JSON 截断、工具名拼写错误等情况。2.3 Harness 常被误解成“调用大模型的封装”有一种很常见的简化理解Harness 就是“把模型请求包了一层”。这种理解会带来两个错误做法一是只封装请求日志不控制工具执行二是把所有控制逻辑直接塞进业务代码导致每个 Agent 的权限规则都不一样。裸 Agent 调用和带 Harness 的调用有本质区别可以用表格对比对比点裸 Agent 调用带 Harness 的调用工具能否真正执行不一定需要业务代码额外解析由执行器统一负责权限控制无统一策略各工具各自判断调前统一检查白名单和参数超时控制工具接口自己实现Harness 统一设置超时并捕获超时异常参数校验通常缺失根据 schema 执行前校验日志审计依赖业务日志Harness 结构化记录 action、params、status、latency人工介入无高危险操作可配置人工确认通道这一层差异在开发环境不明显一旦进入生产环境就会暴露。没有工具的 Agent 只是聊天程序有工具但没有 Harness 的 Agent是“不可控的自动化”这才是很多智能体事故的来源。3. 一个最小可运行的安全带雏形示例结构3.1 目录结构先按模块拆分下面的目录结构是一个通用示例用于说明 Harness 的最小组成。实际项目需要替换包名、路径和依赖版本。agent_harness_demo/ ├── config.yaml ├── main.py ├── harness/ │ ├── __init__.py │ ├── core.py │ ├── security.py │ ├── executor.py │ └── memory.py ├── tools/ │ ├── __init__.py │ └── order_tool.py └── tests/ └── test_harness.pyharness/security.py保存权限策略harness/executor.py保存工具执行逻辑harness/memory.py保存会话上下文。tools/order_tool.py是具体工具main.py是入口config.yaml是运行时参数。把安全控制从工具里抽出来是 Harness 设计里很重要的一点。工具只关心“怎么执行”不关心“能不能执行”。这样换工具、加权限规则、审计日志时都不需要侵入业务工具代码。3.2 YAML 配置先定边界再写代码在写代码之前先把边界写进配置。下面是config.yaml的示例llm: provider: placeholder model: placeholder temperature: 0.2 harness: max_steps: 10 timeout_seconds: 30 tool_allowlist: - order_query - order_cancel deny_keywords: - password - secret observability: log_level: INFO trace_enabled: true这段配置说明了三件事。tool_allowlist决定模型能调哪些工具白名单之外的动作直接拒绝。deny_keywords用来拦截参数里可能包含的敏感信息这是最简单的关键词防线。max_steps和timeout_seconds是资源边界避免 Agent 无限循环或单个请求拖死进程。这里要特别说明provider和model写的是占位符实际项目必须替换成真实可用的大模型服务配置。密钥不要写在这个文件里而是通过环境变量注入。3.3 核心代码权限检查、执行器和主循环先看harness/security.py。它负责检查工具是否在白名单中并拦截包含敏感关键词的参数class SecurityPolicy: def __init__(self, allowlist, deny_keywords): self.allowlist set(allowlist) self.deny_keywords deny_keywords def check(self, action, params): if action not in self.allowlist: return False, action not allowed params_text str(params).lower() for keyword in self.deny_keywords: if keyword in params_text: return False, fparameter contains denied keyword: {keyword} return True, ok然后是harness/executor.py。它负责真正执行工具并统一设置超时import httpx def run_tool(action, params, timeout30): tool get_tool(action) with httpx.Client(timeouttimeout) as client: response client.post(tool.url, jsonparams) response.raise_for_status() return response.json()get_tool需要根据 action 从工具注册表里找到对应工具配置。实际项目中工具可能是内部函数也可能是外部 HTTP 接口超时应该按工具类型分别设置比如查询类 10 秒、任务类 60 秒。最后是harness/core.py它把权限检查、执行器和记忆体串起来class Harness: def __init__(self, config, security_policy, memory, observability): self.config config self.security_policy security_policy self.memory memory self.observability observability def step(self, action, params): allowed, reason self.security_policy.check(action, params) if not allowed: return {status: denied, reason: reason} result run_tool(action, params, self.config[timeout_seconds]) self.memory.append_tool_result(action, result) self.observability.record(action, params, result) return {status: ok, result: result}main.py里只需要创建 Harness然后把它接入大模型循环。3.4 如何运行和验证在获取可用的模型服务配置后可以用下面的命令启动这个示例cd agent_harness_demo python main.py --input 查询订单 10086正常运行时日志里应该能看到类似下面的信息[harness] session_ids_20250101_001 [security] allow actionorder_query [executor] call order_query with params{order_id:10086} [harness] step1 statusok final answer: 订单 10086 已发货。完成基础运行后至少要验证三个分支调用未在白名单中的动作例如delete_file应该返回 denied。参数里包含password或secret时应该被安全策略拒绝。工具响应超过超时时间时应该抛出超时异常而不是无限等待。把这三种情况写成测试用例比只验证“能跑通”更有价值。Harness 的价值正是在异常分支里体现的。4. Harness 到底管控哪些事五个关键边界4.1 工具边界白名单、Schema 校验和结果裁剪Harness 第一件要管的是工具边界。模型不能调用任意函数只能调用 Harness 暴露出来的有限工具集。白名单是最低要求真正落地上还要做三件事。第一每个工具都要有参数 Schema。模型根据 Schema 生成参数Harness 根据 Schema 校验参数。这样可以减少模型凭空捏造字段的概率。{ name: order_query, description: 按订单号查询订单状态, parameters: { type: object, properties: { order_id: { type: string, minLength: 6 } }, required: [order_id] } }第二执行前要做参数校验。比如order_id必须是字符串且长度不小于 6超过长度限制的直接拒绝不进入工具调用。这样可以防止模型把超长文本、注释或注入语句塞进参数。第三工具返回结果要裁剪。大模型上下文窗口有限如果工具返回 10 万字符全部回填背景会导致上下文爆炸。Harness 负责截断、摘要或只保留关键字段。4.2 权限边界凭证隔离与最小权限大模型本身不需要知道数据库密码、第三方平台密钥或完整的内网地址。Harness 的价值之一是把凭证从模型的可见信息中剥离出来同时仍然让工具执行时能够使用。推荐做法是把凭证放到进程环境变量或者放到独立的密钥管理服务中。例如AGENT_ORDER_API_BASEhttps://api.example.com AGENT_ORDER_API_TOKENplaceholder_token工具执行器从环境变量读取这些值并注入 HTTP 请求头。Harness 在组装提示词时不应该把凭证拼进去也不应该把环境变量名暴露给模型。最小权限原则在 Agent 场景里尤其重要。Agent 的行为带有不确定性无法保证模型每次都会选择正确的工具、正确的作用域。给它一个只读账号而不是数据库管理员账号给它一个大模型工具列表而不是所有内部服务直连地址。这样即使模型失误破坏范围也是有限的。容易踩的坑是为了少传几次参数把所有业务凭证都放进一个大 JSON 配置再让工具从这个 JSON 里取。这样等于把整套钥匙挂在了电脑旁只在地图上标注了可以碰钥匙的规则。4.3 资源边界超时、步数和并发资源边界是 Harness 最容易出效果、也最容易配置错的地方。需要关注的参数通常有下面这些参数含义常见值调大影响调小影响max_steps最大 Agent 循环步数5 到 15能处理更复杂任务但 token 成本和耗时上升简单任务更快复杂任务容易中断timeout_seconds单次工具调用超时10 到 60大任务不容易超时但会拖慢整体响应快速失败适合轻量接口max_tokens模型单次输出上限与模型有关回答更完整费用更高输出容易被截断max_concurrency同一 Agent 实例并发上限1 到 10吞吐更高资源压力更大稳定性更强这些参数在开发环境可以放宽但在生产环境必须根据场景收紧。尤其是max_steps如果设置成 100一个出错的智能体可能会在用户看不见的地方连续执行几十次工具调用消耗大量 token还会产生一堆副作用操作。4.4 状态边界会话、记忆和幂等Harness 还要管状态。每次工具调用的结果都要被保存否则模型下一轮就“失忆”。会话状态不是简单地把 message 数组堆在内存里还要考虑以下几点多轮会话如何持久化进程重启后是否能恢复。工具返回结果是否会被塞入下一轮上下文造成 Prompt 越来越长。长任务中断后能否从最后一步状态恢复。更重要的问题是幂等。假设模型决定调用“取消订单”工具第一次调用超时Harness 重试时又调用了一次。如果工具没有幂等键用户可能被扣两笔违约金。Harness 应该在执行这类副作用操作时生成idempotency_key并告诉目标服务“同一个请求键不要重复处理”。一个最小状态结构看起来很简单但在工程上要当作独立模块设计{ session_id: s_001, step: 3, history: [], tool_receipts: [] }4.5 可观测性边界一次操作要留一条完整轨迹Harness 不能只做权限控制还要让每一次 Agent 操作“可回放”。这里的可回放不是输出一句“执行成功”而是能回答以下几个问题这个 Agent 是哪次会话发起的。模型在这一步输出了什么内容。Harness 判断允许还是拒绝判断依据是什么。工具实际执行了多久返回了什么状态。哪一步耗时最长哪一步失败。推荐把日志写成结构化 JSON每一行都带trace_id和session_id{ trace_id: t_001, session_id: s_001, step: 1, event: tool_execution, action: order_query, params_hash: a1b2c3, status: ok, latency_ms: 230 }params_hash可以用来标识参数内容又不会把敏感参数直接写入日志。对于审计场景还要记录“谁的用户、哪个租户、哪个 Agent 版本”发起的调用。5. 学习环境与生产环境的安全带差异5.1 学习环境先跑通循环再谈完备单独开发调试时没有必要一开始就把所有边界都做完整。学习环境的重点是把“模型输出到工具执行到结果回填”这条链路跑通。可以暂时放宽权限控制甚至把白名单放到能放低的程度只要确认代码能处理“允许调用”和“拒绝调用”两条路径即可。学习阶段建议按这个顺序做用本地或测试模型跑通一次没有工具的对话。增加一个只读工具确认模型能输出工具调用意图。增加 Harness 解析和执行逻辑确认结果能回填。再增加白名单和参数校验。最后补日志和异常处理。在只读工具阶段做权限控制不会产生破坏性后果也比较容易写出干净的测试用例。5.2 生产环境必须补齐的七件事从学习环境到生产环境不能只把模型地址换成生产地址。下面这七件事缺一件都可能出事故事项不做的风险配置外置化配置写死在镜像里上线后无法快速调整参数密钥隔离凭证进入代码库或模型上下文泄露风险高日志脱敏手机号、订单号、隐私信息进入日志产生合规风险监控告警工具持续失败或 Agent 循环没人知道降级与回滚新版本 Agent 出问题后无法快速恢复多租户隔离一个 Agent 越权访问另一个租户的数据审计留痕事故发生后无法定位是谁、哪一步触发这七件事不是 Harness 独有的但 Harness 是其中最关键的落地位置。因为 Agent 的工具调用密集且自动如果不在这里统一治理散落在代码各处的逻辑很难形成一致防线。5.3 多智能体场景里的安全带多智能体系统里Agent 与 Agent 也会互相调用。Harness 在这时又增加了一层职责跨 Agent 信任边界。不能把这些 Agent 放在同一个进程里共享同一个特权凭证也不能让任意 Agent 直接访问另一个 Agent 的记忆。合理设计是每个 Agent 有独立身份和独立权限集合Agent 之间的调用走服务接口而不是共享内部对象Harness 在服务边界处校验调用方 Agent 身份。当一个 Agent 要调用另一个 Agent 的“取消订单”能力时Harness 仍然要像对待工具一样做白名单检查。6. 常见问题排查链路6.1 现象工具执行报 401 或 403Agent 配好了模型也按预期选出了工具但工具调用时返回 401 或 403。先按下面的链路排查确认凭证是否真正注入到了 Harness 进程。检查环境变量名和 Harness 读取位置是否一致。确认白名单对象是“工具名”而不是“凭证名”。一些实现会把 action 当作唯一标识但凭证读取失败被误报成权限不足。确认目标服务接受的凭证作用域是否匹配。账号只读权限却调用了写接口会返回 403。确认模型输出中是否没有包含明文凭证。如果模型把密钥当作参数输出说明提示词组装阶段泄漏了凭证信息。排查目标服务是否有时间戳校验。Agent 调用频繁时时钟偏差会导致签名不通过。常见排查表现象常见根因检查方式处理建议401凭证未注入或注入错误打印凭证是否存在不要打印完整值修正环境变量统一由 Harness 注入403凭证作用域不足看目标服务错误详情缩小或调整凭证作用域匹配最小权限403Agent 身份越权访问查看 trace 中的租户和角色字段在 Harness 权限策略中加入租户维度425时间戳/签名失效对比机器时间和服务时间启用 NTP 同步检查签名算法6.2 现象Agent 卡在循环或一直重试Agent 连续执行同一个工具或者反复调用多个工具后回到同一步这是资源边界没有生效的典型表现。排查顺序查看max_steps是否设置过大。调试阶段先调小例如 3 到 5 步更容易复现问题。检查parse_plan是否把模型输出解析成了错误动作。有时模型输出不标准解析器漏掉了最终回答。查看工具返回结果是否可解析。如果工具返回了一个纯文本段落而 Harness 期望 JSON模型可能一直无法理解结果。检查记忆体是否保存了工具结果。如果结果没有回填模型下一轮就忘记了自己已经查过订单。关注模型是否反复选择同一个方法但参数错误。这种情况需要在 Harness 里增加“同类动作连续失败 N 次后停止”的规则。解决时除了调整重试和步数还要在 Harness 里给“连续失败”设一个熔断阈值。比单纯降低max_steps更有效。6.3 现象工具确实执行了但 Agent 回答错误工具执行成功不代表 Agent 理解正确。常见原因有三个。第一工具返回值被截断。上下文窗口有限Harness 如果做了结果裁剪裁剪后的内容可能丢掉了关键信息。此时要检查原始返回值和裁剪逻辑。第二工具返回值虽然执行成功但本身是错误数据。模型无法判断数据是否正确只能基于错误数据作答。建议在工具结果里增加status、error_code字段而不是只返回数据。第三工具参数解析错误。例如模型把日期格式传成了2025/01/01而接口期望2025-01-01。Harness 在 Schema 校验时发现了类型问题但模型不知道校验规则反复传了同样的错误格式。解决办法是执行前校验不通过时把校验失败原因作为系统消息返回给模型让模型修改参数。排查时优先看完整轨迹模型输出端原始计划、Harness 是否允许执行、工具实际收到的参数、工具原始响应、Harness 回填给模型的文本。这五段扣下来错误通常一目了然。6.4 现象日志全乱了找不到一次调用的完整轨迹如果日志里只有零散的模型调用和工具输出没有会话维度串联排查会非常痛苦。根因往往是没有trace_id或者日志字段不统一。标准做法是在 Harness 创建会话时生成trace_id。所有日志包括 LLM 调用、权限判断、工具执行、异常捕获都带上trace_id和session_id。日志输出为 JSON 格式包含事件名、动作名、耗时和状态。使用日志聚合平台按trace_id搜索。最小字段建议time level trace_id session_id event action status latency_ms error_msg这组字段看起来简单但能覆盖 90% 的排查场景。如果连日志都找不到链路那么任何更复杂的监控和审计都没有意义。6.5 通用排错表现象常见根因检查方式处理建议未授权工具被调用白名单配置错误或校验未生效检查 config.yaml 和 SecurityPolicy 日志统一走白名单默认拒绝参数校验失败但模型一直重试校验错误信息没有回传给模型看 parse_plan 和 feedback 逻辑把失败原因作为系统消息返回上下文爆掉工具结果未压缩历史消息无限增长看 memory 保存的内容长度做结果裁剪和摘要Agent 权限过大直接给模型透传了管理员凭证检查凭证管理方式改用只读服务账号和最小权限工具执行成功但无日志工具逻辑未经过 Harness 执行器看工具调用入口所有工具必须经 executor 统一执行7. 设计自己的 Agent 安全带时最值得记住的实践清单7.1 设计原则先限制再放开Agent Harness 的默认姿态应该是“拒绝执行除非明确允许”。这个原则体现在四点上工具白名单默认只开放必要的几个工具而不是把所有接口都暴露给模型。最小权限凭证只给 Agent 完成任务所需的最小作用域。失败关闭安全策略本身出现异常时默认拒绝执行而不是默认放行。可回滚新版本 Agent 或新工具上线出问题时能在几分钟内切回旧版本。这些原则在写第一版 Harness 时就可以定下来越早越好。等事故发生后回头补成本会明显更高。7.2 代码审查时先用清单过一遍给 Harness 做代码审查时不要只看功能流程建议逐条确认下面这些问题每个工具是否有独立的参数 Schema。工具执行前是否检查白名单和参数合法性。凭证是否只存在环境变量或密钥管理服务中。是否有max_steps、timeout_seconds、max_concurrency配置。工具返回结果是否做了长度限制。日志是否包含trace_id、session_id是否脱敏。副作用操作是否支持幂等键。高危操作是否有人工确认入口。会话上下文是否持久化进程重启后能否恢复。多租户场景下权限策略是否包含租户维度。这十条可以作为一份基础清单放进团队的 MR 模板里。每次改动 Harness 或新增工具时都过一遍。7.3 落地顺序建议第一次实现 Agent Harness 时不需要把边界全部做完。按下面的顺序推进每一版都能独立交付和验证。第一版工具白名单 超时控制 JSON 日志。这一版解决“模型乱调工具”和“出问题找不到日志”两个最基础的问题。第二版Schema 参数校验 凭证隔离 状态持久化 结果裁剪。这一版解决“参数错误”和“上下文爆掉”问题同时让 Agent 状态可恢复。第三版多租户隔离 监控告警 降级回滚 审计能力。这一版让 Harness 可以进入严格的生产环境。每版落地后都用测试用例验证三个关键分支允许执行、拒绝执行、执行异常。三个分支都覆盖了再进入下一版。7.4 用一句话记住 Harness 的职责边界Agent Harness 可以与 LangChain 等框架共存也可以单独实现。区别不在于是否用了某个框架而在于执行和治理能力是否独立出来。把本文的内容压缩成一句话模型决定做什么Harness 决定能不能做、做到什么程度、做完会留下什么。对刚接触智能体的开发者建议从一个小型只读工具开始先实现白名单、超时和日志三件事把执行链路跑通再逐步扩大工具范围。在学习阶段就养成“先限制、再放开”的习惯后面进入生产环境时会少踩很多坑。