【Agent-Harness】900 个技能怎么进一个 Agent
900 个技能怎么进一个 Agent：一个能力供给体系的完整演进
Agent 平台改造实录 · 01
这个系列复盘我们在一个生产 Agent 平台上的几场关键改造。它们都发生在模型外围的那一层——业内现在叫它 Agent Harness：agent 循环、工具调用协议、上下文与能力供给、沙箱执行、状态恢复，把一个"会说话的模型"变成"能干活的系统"的全部夹具。这里的题目从来不是让模型变强，而是让这层夹具能上线、能运维、能长大。八篇从模型身边一圈圈长出去，直到整个平台：
- 01（本文）：能力供给——技能体系的三次搬家与四代检索。
- 02：状态与账本——编排/执行分进程、历史/运行态分存储的两场分离。
- 03：行动协议——tool_call 的两类幽灵故障。
- 04：执行环境——沙箱的粒度、归属与休眠。
- 05：监督交互——把"向用户提问"做成一等协议。
- 06：上下文纵深——给 Agent 装记忆的三次返工。
- 07：运行时自身——性能与判活，平台免疫系统的故障预算。
- 08：收官——还没解决的问题，与生产型 Harness 检查清单。
写法上尽量回到第一性原理：不罗列"我们做了什么"，而是推演"约束是什么、为什么只有这一条路"。所有案例真实发生，系统与数值已做脱敏。
先给两个真实数字，来自我们的生产库。
技能目录：两千八百多条记录，其中在架状态的有九百多个。
一个新注册用户系统提示词里的技能菜单：三十八行。
一个声称"会九百多种技能"的 Agent，提示词里为什么只有三十八行？剩下的八百多个去哪了？
这两个数是终态，不是起点。起点的目录只有几个域，专家还是另一个模型实例。目录后来涨到九百，内容按天改，平台按周发。没有一句能把终态说完。把它拆开，是一次从子 Agent 走回来的转向、三次搬家、四代检索，外加一次权限事故。先看全景，后面每一节是它的局部。
图 1：技能供给体系全景——从独立仓库到模型上下文。平台代码里没有技能内容，只认数据库和制品库两个存储接口；菜单和检索是消费端的两个入口。
一、起点：专家不是模型，是文档
最早的形态里，"业务域专家"是子 Agent：主 Agent 判断用户意图属于哪个域，把任务派发给对应的专家 Agent。这套结构在演示里非常好看——架构图上几个专家 Agent 并排一站，颇有些多智能体系统的气派。但生产环境很快教会我们做人，问题全出在一个词上：事务。
一次业务任务的执行，不是一次纯计算，是一连串有副作用的过程：读用户上传的文件、弹表单问用户要参数、等确认、调平台接口、写产物。当这些发生在子 Agent 里，主 Agent 和子 Agent 之间就出现了一条事务边界——用户的回答要跨边界传回去，界面上挂起的表单要跨边界对齐，子 Agent 里读过的文件、踩过的坑，主 Agent 一概不知。用户感知到的是：问过的问题又问一遍，给过的答案丢了一半，"交给专家"之后现场就被清空了。
替代方案是一个认知上的转向，今天回头看也是整个技能体系的第一块基石：
专家不是另一个模型实例，是一份文档。
每个业务域写一份 SKILL.md——业务规则、流程约束、该用哪个命令行工具、什么情况必须向用户确认。主 Agent 的系统提示词只保留一份薄框架，加一条硬纪律："禁止在未加载 Skill 文档时凭记忆执行专用流程。"整条链路变成：模型读用户的话 → 判断该用哪个域 → 读对应的 SKILL.md → 按文档自己执行。
这个转向的本质，是把领域知识从"参数里的权重"变成了"上下文里的文档"。权重里的知识改一次要重新训练，文档里的知识改一次只要重新加载。用操作系统的语言说：主提示词是常驻内存的内核，SKILL.md 是按需换页的进程——地址空间（能力目录）可以远大于常驻内存（系统提示词）。
这个阶段目录很小：几个域专家加若干工具技能，全部摘要注入提示词毫无压力。岁月静好之下埋着两朵乌云：第一朵，技能住在平台代码仓库里；第二朵，目录即将涨一百倍。
二、第一次演进：三次搬家，和"热更新"的真正含义
技能最早住在 Agent 平台的代码仓库里，是普通的静态文件。目录只有几个的时候，这个"住址"毫无问题。但它埋着一个结构性矛盾：
技能是内容，内容的新陈代谢是"天"的节奏；技能住在代码仓库里，代码的发布是"周"的节奏。
改一行技能文案，要走完提交、评审、构建镜像、重新部署平台的全流程。技能作者的迭代速度被平台发版绑架了——更糟的是反向绑架：平台每发一版，都要重新构建一遍和这版代码毫无关系的一堆技能文件。
图 2：三次搬家。每次搬家解决上一住址没解决的问题；终态是"住址消失"——技能对平台而言不再是代码依赖，是数据。
搬家分了三次，一次比一次彻底，每次都在回答上一次没答完的问题。
第一次搬家：进子模块——半独立的假象
技能目录变成平台仓库的一个 git 子模块。技能可以独立提交了，版本历史也干净了，但版本前进仍要平台仓库"bump 指针"，部署仍随平台镜像走。这次搬家的教训是：共享发布管道的"独立"，都是半独立的假象——只要部署还绑在一起，节奏就绑在一起。
第二次搬家：彻底搬出，独立成仓库
平台删掉了子模块引用，技能成为一个独立项目，自带一条发布流水线。这条流水线值得展开讲，因为它定义了技能和平台之间的全部接口——五个阶段，每个阶段都在解决一个具体的传递问题：
第一阶段，构建与上传 CLI。 附带命令行工具的技能按标准 Python 包格式构建成 wheel，传到私有 PyPI。这里有个容易忽略的细节：上传有优先级排序——被依赖的基础库必须先于依赖它的技能上传，否则流水线会在半路撞上"依赖不存在"。
第二阶段，散文件同步。 SKILL.md、参考文档、示例数据，逐文件传到制品库。打进 wheel 的源码文件不再重复上传——一份内容一个权威存放地，其余位置只放引用。
第三阶段，元数据入库。 名称、双语描述、版本、路径、文件清单，upsert 进平台的 PostgreSQL 目录表。两个刻意的决定：其一，本地消失的技能标记弃用而不是物理删除——历史数据里的引用还得能对上号；其二，同步前与网页渠道创建的技能做重名检查，撞名即中止——两个来源往同一张表里写，名字是主键级的契约，不能靠"先到先得"。
第四阶段，整包归档。 整个技能目录打 zip 传对象存储，键是确定性的 {技能ID}/{版本}.zip——同样的内容永远得到同样的地址，天然可缓存、可校验。
第五阶段，向量化。 把"名称 + 双语描述 + 域 + 标签"拼成语料，调向量化模型生成 1024 维向量，写进数据库的向量表。加了内容哈希判重：语料没变就跳过，不重复花钱调模型。
流水线的触发方式最能体现节奏的解放：技能仓库配了 pre-push 钩子，作者 push 的那一刻，五段流水线自动跑完——不需要任何人通知平台"我更新了"。
第三次搬家：住址消失
这是关键的一步，也是最容易被外人忽略的一步：搬家之后，平台代码里不再有任何"技能内容"。平台对技能的全部认知，收敛为两个消费接口——数据库里的元数据目录，制品库里的文件。技能对平台而言不再是代码依赖，是数据。
到这里，"热更新"不是一个需要开发的功能，是分离的自然结果，由三个机制托底：
目录本身是数据。 一个技能要下架，把数据库里的状态位置为"归档"即生效，下一次任何查询都看不见它；要改菜单上那行摘要，改一个字段即生效。平台不重启、不发版、零代码改动。
版本是缓存契约。 每个物化到本地的技能目录带一份版本侧车文件（一个 JSON 小文件），运行时对比侧车里的版本号和目录里的最新版本，一致就跳过下载，不一致才整包重下。所以"内容变了版本必须升"是发布纪律，不是礼貌——内容变而版本不升，已部署的环境永远刷不到新内容，且没有任何报错。流水线对"内容变了版本没升"的提交会警告，但也仅止于警告——契约的执行靠纪律，纪律的漏洞会在第六节算账。
调试期的两个旋钮。 强制重下（无视侧车全量刷新，给技能作者改完即生效的体验）；CLI 自动升级（比对沙箱里已装的工具版本，旧了就从私有 PyPI 升级，检查结果带缓存避免每轮重复查询）。
增量同步还有一段值得记录的设计：流水线用一个存放在制品库的游标（上次同步到的 commit 哈希）做增量规划——本次 push 用 git diff 上次游标..当前 找出变更和删除的技能，只同步差异部分。这里有个防御性细节：如果游标指向的 commit 在本地找不到、或者历史发生了分叉，流水线硬失败而不是猜。因为增量规划一旦基于错误的基线做反向 diff，会把别人的技能"同步删除"掉——宁可停下来要人介入，也不默默地毁数据。
第一性表述：把能力的内容和能力的消费方式分开——内容是数据，走数据管道；消费是代码，走代码管道。数据不需要发版。 这条原理本系列的第二篇还会再次应用——历史与运行态的分离，同宗同源：读者不同、变更节奏不同的东西，不该住在一起。
三、第二次演进：目录爆炸，菜单与仓库分家
然后，一批开源技能集合进来了，目录从几十涨到九百多。怎么让模型"知道自己会什么"？
朴素答案是把所有技能的描述塞进系统提示词。我们没有这么做，因为三笔账都算不过来。
第一笔，体积账。 技能的 description 字段不是写给人看的简介，是喂给向量检索的语料——为了让搜索能召回，里面堆满同义词、匹配短语，实测单个从一两百字符到一千五百多字符。九百多个全塞进提示词，是六七十 KB 起步、几万 token 的常驻开销，每一轮请求、每一次模型调用都要原样付一遍。
第二笔，准确率账。 这笔账比体积账更致命。三十八行里选对一个，和九百行里选对一个，是两种难度的任务——菜单越长，噪音越大，"判断该用哪个技能"这个动作本身会变得不可靠。全量注入不仅贵，还会让路由质量随目录规模单调劣化。规模伤害的不只是预算，还有精度。
第三笔，职责账。 这是三层里最深的一层：description 的读者是检索引擎，它要的是关键词密度；菜单的读者是模型，它要的是一句人话。一个字段伺候两个主人，就得在两种写法之间和稀泥——结果是检索不够准，菜单又不够短。
三笔账指向同一个第一性结论：
"知道自己会什么"是判断问题，"拿到具体能力"是获取问题。 判断需要一份低噪音的精选清单，获取需要全量的长尾覆盖。目录小的时候，一个机制可以兼职；目录大了，兼职必然两头失守。
类比很日常：餐厅的菜单和后厨的仓库。菜单印三十八道精选，仓库存九百种食材。没有人把仓库台账印在菜单上——那不叫菜单，叫库存报表。
落地：两层路由
图 3：两层路由与权限门。菜单管判断（低噪音精选），检索管获取（全量长尾）；无论从哪个入口进来，都过同一道"用户启用"的门。
第一层，菜单（系统提示词内）。 内容是该用户的启用集。新用户注册时自动预置精选的内置技能——预置是幂等的，且只在用户一行配置都没有时执行，用户主动关掉的技能，不会因为重新登录被复活（这个细节是刻意的：权限语义里，"尊重用户关掉的东西"比"给用户全部东西"更重要）。之后用户在设置里开关增删，菜单随之变化。菜单渲染出来是这样：
<skill_system>
内置工具
- name: job-runner
description: 查询、运行、管理任务模板、实例与执行记录
数据质检
- name: batch-qc
description: 对上传的数据文件做质量检查，输出异常项
…（按域分组，新用户共 38 行，约 2-3 KB）
</skill_system>
那行"一句人话"，是专门新加的字段 brief——这就是职责账的解法：description 留给检索引擎，人工撰写、硬截断 50 字的 brief 给模型菜单，brief 为空时回退到 description 截断兜底。一份数据有两个消费者，就为每个消费者提供它自己的表示。
后来的一次生产库核对，成了这套设计最漂亮的佐证：九百多个技能里，只有三十多个填了 brief——恰好就是进菜单的那批精选内置技能。没有任何行政命令要求"只给精选技能写 brief"，分工自己收敛了：长尾技能不进菜单，没人有为仓库里的存货写菜单文案的动力。两个消费者、两份数据、两种填写策略，自然到达正确的稳态——因为分工本身是对的。
顺带一个压力场景：评测账号会把全部九百多个技能全部启用，菜单膨胀到几十 KB。这是故意造出来的极限环境，专门测路由能力的天花板；普通用户永远碰不到这个量级。但它的存在本身就是一个提醒：菜单的体积上限由"单个用户最多启用多少"决定，而不是"目录里有多少"——这是分层留给规模的逃生口。
第二层，检索（工具调用）。 菜单挑不准时，模型调 skill_search 工具，覆盖全部九百多个在架技能。判断的兜底是三级的——菜单直选（确定性场景，精选专家路径固定）、检索（模糊场景）、通用工具（前两级都落空时）。配合"禁止凭记忆执行"的纪律，判断失败的最坏情况被框住了：选错顶多多走一步，不会瞎编流程，也不会死锁在找技能上。
四、第三次演进：检索的四代
第二层路由说起来一句话，做起来是四代演进——每一代都在解决上一代暴露的真实问题：
图 4：检索四代。每一代的问题，都是上一代的答案制造出来的。
第一代：关键词检索——语义鸿沟
检索工具诞生于数据库目录上线时，最初就是词法匹配：把关键词和目录里的名称、描述做匹配。工程上简单可靠，问题出在语言上：语义鸿沟。用户说"算那个达标阈值"，技能名里写的是一个英文缩写；中文提问、英文技能名、行业黑话、同义改写——关键词对不上就是零召回。零召回在模型眼里的表现是"我不会"，在用户眼里是"平台没有这能力"。检索的失败是静默的，它伪装成能力的缺失。
第二代：本地向量索引——漂移的教训
语义鸿沟的标准解法是向量检索。第一版实现很直接：给数据库装向量扩展之前，先用 SQLite 的向量扩展在 worker 本机建索引，配一个离线构建脚本。想法直接，问题也直接：索引跟着构建它的机器走。
多 worker 部署时，各机器的索引新鲜度不一致——谁刚跑过脚本谁的索引新；技能更新后，要有人记得在所有机器上重跑；渐渐地，"跑脚本"成了没人愿意认领的运维负债。这一代留下的教训值得刻在墙上：
旁路构建的状态，一定和主数据漂移。 索引不该是散落在计算节点上的产物，该长在主存储里，随主数据同源更新。
第三代：pgvector 混合检索——同源、融合、灰度
第三代把前两代的教训全部兑现：
索引同源。 数据库换成带向量扩展的镜像，索引的写入纳入发布流水线的第五阶段——技能发布即向量化，索引和目录永远同步。从此"重建索引"这个词从运维词典里消失了。
混合检索。 纯语义检索并不比纯词法全面胜出：精确的技术名词、缩写、代码符号，词法反而更准；自然语言描述、跨语言，语义更准。所以两路召回并行——词法一路、语义一路——RRF 融合排序，权重可调。还支持一个贴心的小设计：模型可以在一次查询里用分隔符声明多个独立的检索方向，各自走语义检索再合并——因为"一句话里其实问了两个方向"是真实高频的场景。
双兜底。 向量服务故障时自动退回纯词法——可用性优先于先进性；融合结果为空时模糊匹配兜底——宁可给一个近似的候选，也不给一个空列表把模型逼进死角。
shadow 灰度。 新检索链路上线不是一刀切换，而是先跑"影子模式"：新链路不生效，只把新旧两路的召回结果并排记进日志，跑够了真实流量、人工对账确认新链路不劣化，才切为默认。灰度通常认为是给流量的，这里是对真理的——先证明更好，再成为默认。
这一代还顺手做了一次预防性手术：检索链路改成原生异步。起因是发现旧实现在事件循环线程上临时起一个子事件循环跑同步数据库调用——任何在共享线程上的"临时"同步化，都是全租户停摆的种子（这个种子长成的完整事故，第七篇会讲到；这次不用事故来教，先做了手术）。
第四代：search 与 select 分家——探索与加载是两种动作
第四代是产品语义上最重要的一次拆分。此前"检索"和"加载"混在一个动作里：模型搜到技能，再自己去拼路径读文件。混装的代价在三个维度同时显现：检索结果的形态（给摘要还是给全文？）、加载的可靠性（名字是精确的还是相似的？）、权限的口径（谁都能加载吗？）。拆成两个模式后，每个维度都有了干净的答案：
search——探索。 接受自然语言描述，语义检索，只返回摘要列表。目的单一：帮模型找到候选的名字，仅此而已。不给全文是刻意的：防止模型从搜索结果里"学"到半截流程就开跑——那是变相的凭记忆执行，违反第一节的纪律。
select——加载。 接受精确的名字（支持逗号分隔批量），确定性命中：按名查目录、物化进沙箱、把 SKILL.md 正文直接内联返回给模型——不再让模型自己 read_file。这一步消灭了一整类故障：路径是内部实现细节，让模型猜路径必然猜错，不如把正文递到它手里。
两模式的本质：
检索系统要服务两个不同的动作——"探索"要召回率和模糊容忍，"加载"要精确性、副作用和权限校验。 一个工具两个 mode，好过两个语义含糊的工具。
而"精确性"的最后一课，是一次真实的权限事故教出来的。select 早期的实现是按精确名加载、不做启用校验——逻辑上似乎说得通："模型都点名了，说明它知道要什么。"但换到用户的视角完全是另一回事：用户明明在设置里关掉了一个技能，模型仍然能点名把它加载回来。用户的选择被模型的记忆绕过了。 修复是把 select 和 search 的口径强制统一：所有的入口——菜单、search、select——都过同一道"用户启用"的门。这次事故沉淀出一句话：
权限漏洞最常见的藏身处，就是功能相似的多个入口里，口径不一致的那一个。
主门有保安，侧门没锁，等于没保安。
这四代的节奏还有一层值得点破：每一代的问题，都是上一代的答案制造出来的。词法检索制造了语义鸿沟，本地索引制造了漂移，集中式检索稳定之后才暴露出"探索与加载混装"的产品语义问题。这不是计划失误，是演进的常态——第一代系统的职责就是暴露真实约束，等你带着伤疤回来做第二代。
五、深潜：一次 select 调用的完整旅程
前四节讲的是体系的形状，这一节把镜头拉近，跟着一次真实的 select("batch-qc") 走完全程。选它是因为这条路径串起了所有子系统——目录、缓存、沙箱、制品库、CLI 供应链。先看时序图，再逐站展开：
图 5：一次 select 的六站旅程。慢路径（下载、同步、安装）全部旁路到线程池，主链路只做查表与拼接；任何一站失败都不静默。
第一站：权限门。 工具解析出技能名，先查目录表——SQL 里带着启用过滤（当前用户的启用表，无用户上下文时回退全局内置标记）。用户没开这个技能，在这里就结束了，返回里明说"不可用"。权限校验永远是第一站，不是"查到之后再过滤"。
第二站：版本对比。 命中后看本地共享缓存目录里的版本侧车文件。侧车版本与目录一致——跳过下载，直接进第四站。不一致或开了强制重下——进第三站。
第三站：物化。 从制品库逐文件下载到共享缓存目录。两个工程细节：每个技能目录有一把自己的锁——同一技能的并发物化（比如多个会话同时 select 它）串行执行，防止互相覆写一半的目录；下载跑在专用的小线程池里——物化是慢路径（网络 IO），绝不上事件循环——这条原则为什么值一条命，第七篇会用一次全租户停摆来称。缓存是共享的：所有会话共用一份技能文件，不是一个会话一份。
第四站：沙箱同步。 把缓存目录增量同步进这一轮的执行沙箱，挂在固定路径下。从此模型眼里，技能就是沙箱文件系统里"一直在那里"的文档——它不知道也不需要知道背后的下载、版本、锁。
第五站：CLI 体检。 如果技能声明了附带的命令行工具，比对沙箱里已安装的版本和私有 PyPI 上的最新版，旧了就升级（检查结果带几分钟缓存，同一轮内不重复查）。文档教模型"怎么用"，这一站保证"真的能用"。
第六站：正文内联。 最后，SKILL.md 全文直接拼进工具返回值，连同技能的根路径一起递给模型。物化链条上任何一站失败——下载超时、文件缺失、CLI 装不上——错误不静默，以 materialize_error 字段内联进返回值。模型看得到失败，才能决定绕行（换一个技能、或告知用户），而不是拿着一份来路不明的半成品继续跑。
这条链路的设计观察，可以浓缩成两条：慢路径全部旁路（下载、同步、安装都在线程池里，主链路只做查表和拼接），失败全部显式（宁可返回带错误的成功，不做静默降级）。前者保护平台的吞吐，后者保护模型的判断权——它是这个系统里另一个"读者"，它的读者权也该被尊重。
六、代价与未解决的问题
到目前为止讲的都是走通的路。诚实的复盘需要把没走通的和还在流血的也摆出来——这一节的内容和前面的成功同样值钱。
版本纪律靠人，而人会懒。 “内容变了版本必须升"是缓存契约的根基，但流水线对违反者只能警告。技能作者改了文档忘了升版本，已部署环境永远 stale，且无任何报错——这类问题一旦发生，排查成本极高，因为症状（模型行为"过时”）和原因（缓存未失效）隔了三层。终极解法是把内容哈希纳入侧车对比，但我们还没做。
菜单体积仍随启用数线性增长。 分层把上限从"目录大小"改成了"单用户启用数"，但没有改变线性本身。一个重度用户开两百个技能，就要付两百行菜单。真正的下一级应该是"菜单也动态化"——按会话上下文检索式注入候选——但那会把判断的可靠性重新交给检索，是个需要勇气的循环。
检索质量没有系统化评测。 shadow 日志靠人工对账，没有常驻的评测集和自动化的新旧链路对比。"检索变好了没有"目前是一个半定量的问题。这在检索系统里是欠账最多的一块——它的完善度决定了"菜单缩小"那条路什么时候敢走。
目录状态与物化缓存之间没有事务。 技能在目录里刚被置为归档，本地缓存和沙箱里的那份还在——正在执行的轮次不受影响（这其实是对的），但"缓存何时回收"目前只有粗粒度的策略。分离式架构的固有代价：省掉了跨系统事务，就要接受各份副本的短暂不一致，并用补偿逻辑兜住（第二篇的老朋友）。
brief 的覆盖止步于精选集。 长尾技能靠 description 截断兜底，截断出来的"一句话"质量参差。如果未来菜单要向长尾开放，这里是第一个要补的课。
七、收束：能力供给的规模解耦
回头看这几次演进，它们各自回答了一个正交的问题：
- 搬家回答"谁跟谁一起变"：内容和消费分管道，技能迭代从周节奏变成分钟节奏，平台零改动；
- 分家回答"判断和获取怎么分"：菜单放精选、仓库放长尾、检索做桥，目录涨十倍提示词纹丝不动；
- 四代检索回答"入口怎么长出来"：从能用到好用，每代兑现上一代的教训；
- 拆模式回答"语义怎么框住"：探索与加载各得其所，权限一道门管所有入口。
五条可迁移的原则，按出场顺序：
- 专家是文档，不是模型。 领域知识放上下文里，不放权重里——前者改一次只要重新加载。
- 内容与消费分离，是热更新的充要条件。 想让什么东西"改了就生效"，先问它是不是数据；不是，就想办法变成数据。
- 判断与获取分层。 任何"能力目录"膨胀到几十项以上，都值得问一句：这份清单是给谁判断用的，还是给谁获取用的？
- 一份数据多个消费者，就给每个消费者一份表示。 description 和 brief 不是冗余，是接口。和稀泥的共享字段，最终会同时得罪所有读者。
- 功能相似的多个入口，权限口径必须同一。 漏洞不住在主门里，住在侧门的缝里。
而技能体系这一篇，还藏着一个比"900 个技能"更一般的命题——它也是生产型 Agent Harness 的第一课：同一个模型，能力的边界由夹具层决定。 任何一个系统，只要它的能力目录、知识库、工具集会持续增长，"怎么让模型知道自己会什么"就不是一个提示词工程问题，是一个供给体系设计问题。菜单、仓库、检索、版本、权限——这套词汇表不属于 Agent，属于一切做平台的人。我们只是在自己的场景里，把它们一个一个重新发明了一遍。
这是第一篇，讲的是模型身边最近的问题：Agent 怎么知道自己会什么。接下来的七篇一圈圈往外长——第二篇讲对话留下什么：状态与账本的两场分离；第三篇讲它怎么行动：工具调用协议的幽灵故障；第四篇讲行动落在哪里：沙箱的粒度、归属与休眠；第五篇讲人怎么介入：把等待做成一等协议；第六篇讲它跨会话记得什么：记忆的三次返工；第七篇讲平台怎么活下来：性能与判活；第八篇收拢成一份清单。八篇连起来，是一个生产型 Agent Harness 从"能跑"到"能运维"再到"能长大"的完整剖面。
为保护项目与客户信息，文中系统名、工具名、业务场景和具体数值均做了抽象或区间化处理；技术结论不受影响。
更多推荐
0
0- 0
已为社区贡献1条内容
所有评论(0)