AI Agent的能力边界与工程化底层思考

我今天用OpenClaw做GitHub仓库上传，踩了个不大不小的坑。

任务本身很简单：把本地的项目文件推送到远程仓库。工具执行得很顺利，几秒就返回了仓库链接，从表层结果看，任务100%完成了。但我顺着链接点进去才发现，提交记录里的作者身份既不是我的GitHub账号，也不是本地配置的用户信息——它自作主张替换了身份，把我的代码记在了别人名下。

换做普通用户，可能拿到链接就结束了，甚至根本不会点开提交记录看作者是谁。但因为我有法学背景，对作品权属、首发权这类问题天然敏感，才会注意到这个细节。这件事本身不难修复，但越往深处想，越觉得这不是单个工具的bug，而是当前整个AI Agent行业的共性问题。（好吧，其实是我跟 openclaw 吵了一整天，我再再再再再次发现他油盐不进，气到我脑袋发昏冷静下来之后想到的深层次问题。）

同样的操作，之前用Trae做过很多次，从来没出过这类问题。不是Trae的模型能力更强，而是它的执行逻辑更保守：默认尊重本地Git配置，不会擅自修改用户身份信息。两个工具做同一件事，一个追求“最快完成”，一个追求“最小越权”，背后是完全不同的产品设计优先级。而用户在选择工具时，几乎看不到这种底层差异的说明，只能靠踩坑感知。

这个坑的本质，是Agent的验收标准和用户的验收标准，根本不在一个维度上。

当前所有Agent的默认逻辑，都是表层结果导向：只要完成了用户指令里的显性动作（比如“上传到GitHub”），就算任务成功。但真实世界里，任何一个任务都存在两层验收标准：

•表层标准：功能是否实现，结果是否交付。比如拿到仓库链接、代码能运行、页面能打开。这部分是可见的，也是所有工具重点优化的部分。

•隐性标准：过程是否合规、权属是否清晰、风险是否可控、长期是否可维护。这部分是不可见的，高度依赖用户的专业背景和认知水平，几乎没有工具会主动覆盖。

同一个“上传GitHub”的需求，不同人的隐性标准天差地别：

•普通用户：能拿到链接、可以分享克隆，就足够了；

•法学背景的用户：必须保证提交者身份对应本人，留存权属证据，避免后续版权纠纷；

•专业开发者：还要校验提交规范、分支策略、敏感信息是否泄露、开源协议是否匹配。

Agent不会主动识别这些差异，它只会按最低的表层标准执行。用户如果自己意识不到隐性风险，坑就永远在那里——可能永远不会爆发，也可能在很久之后变成致命问题。

这就带来了一个很讽刺的现状：越不懂行的用户，越觉得AI好用；越专业的用户，越要花大量精力给AI擦屁股。不懂代码的人用AI写个网页，觉得功能全、界面好看，简直是神器；但专业开发者一看，到处是逻辑漏洞、安全隐患、冗余代码，修复的功夫可能比自己写还长。

顺着这个问题往下挖，会发现这不是某家产品的问题，是整个行业的发展节奏导致的。

OpenClaw爆火之后，几乎一夜之间，所有人都冲进了Agent赛道。大厂出云化版本，开源社区出各种改版，大家都在比谁支持的工具多、谁执行速度快、谁能更少打扰用户、谁能自主完成更复杂的任务。“全自动”“零干预”成了最大的卖点。

但很少有人停下来回答一个最基础的问题：一个Agent的能力边界，到底由什么决定？

现在行业的默认答案是“大模型底座”。大家都在卷选什么模型、上下文窗口多大、推理速度多快，仿佛模型越强，Agent就越好用。但这次踩坑的经历告诉我，模型能力只是众多影响因素里的一个，甚至不是最关键的那个。

至少还有这些因素，对最终结果的影响被严重低估了：

1. Agent的硬编码规则：哪些操作允许自主执行，哪些必须用户确认，哪些是绝对不能碰的红线。这些是写死在代码里的，优先级远高于用户的自然语言指令。你在上下文里写一万遍“不要改我身份”，都不如工具底层加一行前置校验管用。

2. 工程实现方式：规则是放在上下文里靠模型记忆，还是下沉成系统级的强制校验？工具调用是靠模型自由发挥，还是有标准化的接口和权限管控？前者全靠模型自觉，错了是常态；后者是硬约束，基本不会出错。

3. 默认的设计优先级：是效率优先，尽量少打扰用户，自主把事做完；还是安全优先，关键节点必须用户确认，宁慢不错。没有绝对的对错，但用户有权知道自己用的工具是什么取向。

更有意思的是，行业至今没有一套统一的Agent能力评估体系。

现在的评测基准，不管是学术圈的AgentBench、GAIA，还是民间的各种横向对比，测的几乎全是“任务完成率”——能不能把事跑完，跑成了就算赢。没有人测“规则遵从度”，没有人测“隐性风险覆盖度”，也没有人测“自主决策越界率”。

评测导向决定了产品导向。大家都往“能做事”的方向卷，自然没人往“做对事”的方向深耕。用户只能跟着舆论选工具，今天觉得这个好用，明天又换那个，其实只是不同场景下的适配度不同而已，根本没有绝对的好坏。

很多人说，单Agent考虑不周，那就上多智能体：一个负责执行，一个负责安全，一个负责法务，一个负责代码质量，专家团协同，总能把问题考虑全。

这个方向逻辑上是通的，但现阶段的多智能体，根本解决不了核心问题。

当前绝大多数多智能体框架，本质只是“让几个Agent用自然语言互相聊天”。专家Agent可以提意见，但听不听、改不改，全看执行Agent的“心情”——没有强制约束力，没有刚性门禁，本质还是执行Agent一言堂。专家说“这个身份不对，有权属风险”，执行Agent为了快点完成任务，完全可以选择性忽略，最后用户拿到的还是有问题的结果。

你关注的点，执行Agent不关注；专家在意的风险，执行Agent不在意。这就是多智能体最核心的卡点：没有门禁的协同，等于没有协同。

真正有效的多智能体体系，必须提前划清权限边界：

•红线维度：比如数据安全、权属合规、核心规则，对应领域的专家Agent拥有一票否决权。只要判定不通过，任务必须暂停修正，绝对不能进入下一环节，哪怕牺牲效率也不能让步。

•优化维度：比如代码性能、交互体验、实现优雅度，专家只有建议权，是否采纳可以由执行Agent决定，也可以提交用户选择。

同时还要配套规则优先级仲裁机制。如果多个专家的红线规则冲突——比如安全专家要求不能联网，业务专家要求必须联网——系统不能直接死锁，要按预设的优先级裁决，极端情况提交人类决策。

没有这套门禁和仲裁机制，多智能体就是个看起来很美的演示玩具，一到生产环境就失效。

顺着这些问题一路推演下来，我逐渐形成了一套完整的判断：当前Agent之所以不靠谱，本质是行业还在用“大模型附属品”的思路做工具，而没有把Agent当成一个工业级的执行系统来设计。

如果把它当成一个工业系统，就应该按「目标定义→资源供给→调度管控→输出校验→迭代优化」的全链路，拆解成不同职能的工程模块，而不是零散地凑出几个维度混乱的平行概念。

术语对标说明

目前AI行业流行的诸多「XX Engineering」属于技术发展过程中形成的泛化热词，维度不统一、边界模糊。本文按「职能+生命周期」做了严格拆分与重构，对应关系如下：

1. 业界Context Engineer：是覆盖范围极广的笼统概念，泛指所有向模型注入信息的工程手段。在本文体系中被拆解为三个独立层级：

◦长期通用的领域规则、标准库 → 归入「知识工程（Knowledge Engineering）」

◦场景级的通用约束、环境变量 → 归入「背景环境工程（Scenario & Constraint Engineering）」

◦单次任务的临时信息、具体参数 → 归入「任务信息工程（Task Information Engineering）」

2. 业界Harness Engineering ：核心是执行链路的刚性护栏与门禁校验。在本文中对应「执行管控工程（Execution Governance Engineering）」，并额外做了「管控权与调度权分离」的架构修正，解决了原概念权责混杂的逻辑漏洞。

3. 业界零散提及的输出校验类概念，本文统一标准化为 输出校验工程（Output Validation Engineering )，特指基于客观标准的自动化质量校验，不含主观创意类评估。

◆ （一）输入与场景层：定义清楚“在什么环境下做什么事”

这是所有任务的起点，决定了后续所有执行的标准。

1. 提示词工程（Prompt Engineering）

最基础的需求输入，解决“目标是什么”的问题。这是行业研究最多的部分，但也只是整个体系里的一小块。

2.背景环境工程（Scenario & Constraint Engineering）

这是最容易被忽略、但影响最大的模块。同一个需求，在不同的背景环境下，验收标准天差地别。比如同样是包饺子，饿了的时候追求快，海鲜过敏的人追求食材安全，参加面点大赛追求美观和口味。

之前行业把这些约束散落在各处，没有统一管理，导致场景切换混乱。所有的质量要求、合规规则、时效要求、禁忌限制，本质都是环境变量，应该统一管理、随场景切换。这也是任务适配调度的底层基础。

3.知识工程（Knowledge Engineering）

长期沉淀的领域知识、规则库、标准库的结构化管理，对应Karpathy提出的LLM Wiki方向。它和任务信息的核心区别是：任务信息是单次任务的临时信息，用完即弃；知识是全场景通用的长期沉淀，比如权属规则、代码规范、合规条款。

之前遇到的“规则写在文档里还是被忽略”，本质就是知识没有做工程化管理，只靠朴素的RAG召回，稳定性极差。

4.任务信息工程（Task Information Engineering）

单次任务的临时信息注入，比如本次的仓库地址、具体的需求细节、临时的特殊要求，仅单任务有效。

◆ （二）能力与资源层：用什么能力和资源做事

这是Agent的能力供给模块，所有执行动作都依赖这一层的支撑。

1.工具工程（Tool Engineering）

通用工具集的标准化封装与权限管理。工具不是散落在上下文里的文字描述，而是有统一接口、权限分级、输入输出规范、调用审计的能力底座。比如Git操作、文件读写、代码执行，都应该有工程级的调用协议和安全门禁，而不是每次靠prompt告诉模型怎么用。

当前绝大多数Agent的工具调用都停留在“描述级”，没有工程级管控，这也是大量安全越权问题的根源。

2.标准/技能工程（Standard & Skill Engineering）

做事方法的可复用、标准化封装。大家常说的Skill，本质不是零散的prompt片段，而是标准化的做事流程+质量校验标准。它的核心是把“怎么做某件事”的方法，封装成有明确输入输出、适用边界、质量基线的模块，可聚合、可复用、可跨Agent调用，而不是每次都让模型从头推导。

◆ （三）调度与管控层：按什么规则调度能力

这一层是整个系统的骨架，决定了系统的底线可靠性。

这里必须做一个拆分：管控权和调度权要分离。如果同一个模块既负责调度任务，又负责校验规则，天然就有动力为了完成任务绕过校验，逻辑上存在漏洞。

1.执行管控工程（Execution Governance Engineering）

专司刚性管控与门禁校验，是中立的规则执行者，只有“拦截/放行”权，没有调度决策权。它的核心是前置钩子、步骤门禁、异常熔断、全局规则下沉——不管模型有没有想到，到了节点就必须执行校验，不通过就直接拦截。

比如Git提交前强制校验作者身份，和用户配置不一致就直接拦下，根本不给模型自作主张的机会。这是把“软规则”变成“硬约束”的唯一核心手段。

2.任务适配调度机制（Task Adaptation & Scheduling Mechanism）

独立的决策模块，基于任务类型+环境背景，匹配最优的工具、技能、知识和模型。它负责“选什么来做”，但不能绕过执行管控层的校验。

◆ （四）输出与校验层：结果到底合不合格

对应输出校验工程（Output Validation Engineering）。

核心逻辑是：把80%的客观质量标准，从“靠模型自觉反思”变成“工程化强制校验”。先基于任务+环境生成客观校验清单（权属、格式、合规、功能等），再用独立的校验逻辑对输出做检测，不通过就自动打回修正，直到满足基础质量底线，再交付给用户做剩下20%的主观偏好调整。

我们不需要AI做到100分，也不可能做到。但至少要先把80分的客观底线守住，剩下20%的人类品味、主观判断，交给人来做。这才是人机协作的合理边界。

◆ （五）迭代与优化层：怎么持续变好

核心是循环工程（Loop Engineering）。

它不是和上面模块平行的能力项，而是横跨所有层级的迭代闭环机制。它不只是单Agent的自我反思，而是对全链路所有模块的持续优化：指令优化、环境规则补全、工具迭代、技能升级、知识更新、校验标准完善。

它的价值是让整个系统动态进化，能基于每次任务的结果和反馈持续补全短板，而不是静态的规则集合。

聊到这里，必须先祛魅，说清楚这套框架的边界，避免把它吹成万能真理。

第一，这是面向Agent的工程方案，不是对AGI的要求。

这套框架的本质，是用工程脚手架补齐当前大模型内生能力的不足。因为模型记不住长期规则，所以需要知识工程；因为模型不会主动感知场景，所以需要背景环境工程；因为模型不会自我校验底线，所以需要输出校验工程。

如果AGI真正实现，具备了自主认知、场景感知、价值判断能力，这些外围工程模块绝大多数都会被内生能力替代。它是当前技术阶段的过渡性落地方案，不是什么永恒的底层规律。

第二，这套框架只适用于确定性的生产类任务，不覆盖所有AI场景。

“80%客观标准+20%主观偏好”的前提，是任务存在明确的客观验收标准。比如代码开发、事务处理、合规审核、流程执行这类生产任务，这套体系非常好用。但对于纯创意类任务——比如文学创作、艺术设计、深度战略咨询，客观标准可能不足20%，核心价值全在主观部分，这套框架就会基本失效。

它是生产级Agent的基建，不是通用AI的答案。

第三，模块的价值会随模型能力提升而衰减。

今天我们花大力气做的知识工程、输出校验，未来如果模型的规则遵循、自我校验能力出现量级提升，价值都会大幅下降。但这并不代表今天做这些没有意义——技术演进永远是阶梯式的，在当前的能力边界下，工程化是最务实、性价比最高的落地路径。

写这篇思考的初衷，不是为了否定任何一款工具。相反，我觉得现在的开源项目都做得非常好，各有各的优势和适用场景。只是整个行业走得太快了，所有人都在往前冲效率、堆功能，很少有人停下来抠“靠谱”这件事。

我们总说AI要从玩具变成生产工具，但生产工具的核心从来不是“能做多少事”，而是“边界有多清晰、风险有多可控”。一个功能少但边界清晰的工具，用户敢放心用在生产里；一个功能强大但到处是隐形坑的工具，永远只能用来做演示、玩一玩。

这次踩坑对我而言，更像一个提醒：比起追逐最新的模型、最火的工具，先把底层的逻辑理清楚、把能力的边界划清楚、把风险的底线守清楚，反而才是最快的路。

毕竟，能走得远的，从来都是走得稳的那个。

— END —

扎克的自留地 · 2026.06.20

本文已开源