最近终于敢碰托管 agent 了：bl managed-agent 本地五步走完，不带确认参数只给预览、云上零创建 # 拖了挺久，卡在两个怕上

最近终于把托管 agent 这件事捡起来了。

说来惭愧，这个念头在我这儿放了挺久。想跑一个能自己接着往下干活的东西，给它一段说明，它自己安排后面的步骤，不用我每一步都盯着。听着挺美，一直没动手。

原因不是不会写，是两个怕。

一是怕那些配置文件。agents.yaml、environment、vault、deployment，名词一层压一层，缩进差一格、字段名少一个字母，我不知道会炸在哪儿，更不知道炸的时候云上是不是已经留下东西了。

二是怕手滑。一个会自己跑的东西，建出来只要一条命令，删干净可能要翻好几个地方，还得回头确认它是真的停了。我不太想在云上留一个自己都不敢碰的物件。

结果这次上手，两个怕都被同一件事解掉了：这组命令把预览和执行分成了两件事。不带确认参数，它只给你看将要发生什么，一件都不会真做。

那条线是命令自己画的

我原来的心智模型很朴素：命令行工具就是一把锤子，敲下去就生效，出事只能靠备份兜着。

bl managed-agent 不是这样。它在预览和执行之间画了一条很硬的线，而且这条线不靠我的自觉守，是命令自己守的。我想真执行，就得自己显式加上确认参数，那是另一次独立的决定，不是上一条命令的顺手延续。

这个设计对怕手滑的人价值很大：我可以把预览类命令反复跑，跑上十遍也不会留下任何后果，只为了看清它到底打算干什么。

命令行的安装说明在一条命令装完的 CLI 安装页，Key 等你以后要用别的命令再去密钥管理页领就行，下面这五步根本不联网。

五步，全在本地

我专门找了个空目录当试验场，产物全落在里面。混在家目录以后不好收拾，这点建议照做。

第一步叫 init，生成一份脚手架配置。想跟着走的话就这一句：

bl managed-agent init

有个能改的起点，比对着空白文件从头写字段名舒服太多。

第二步叫 validate，检查这份配置，而且这个检查是离线的，一个网络请求都不发。写完配置想知道对不对，本地就有答案，这个答案还可以反复问。

第三步叫 plan，回答现在执行会发生什么。脚手架刚生成、我什么都没改的时候，它明说没有任何待执行的变更。这条命令可以随时跑，跑了也不留后果，我后来养成了改完就 plan 一次的习惯。

第四步换一种形态：一条 project init 下去，建出一个目录项目。我数了一遍，32 个文件，里面有一个本地版本库、一份 agent 配置，还有技能、文件、密钥、环境四类资源的示例和双语说明。

让我松一口气的是，示例默认不启用也不发布，想用得按说明复制出来再配引用。脚手架不会顺手把示例推上去，它只是把架子摆在我面前。

落点也顺便看清了：顶层只多了一个 .bailian 目录，技能内容都在它下面的 skills 子目录里。知道东西落在哪，以后 agent 读的是哪一份就不用猜。

第五步是创建，我只跑了预览，后面单独说。

踩的那个坑，跟 YAML 一点关系都没有

第四步我卡了一下，记一笔给后来人。

目录项目的检查和构建，必须站在项目目录里跑。

我在外层目录跑检查，它直接拒绝继续，只回一句 Directory project validation failed.。信息量少到我一时不知道该查什么，第一反应居然是我配置是不是写错了，回头翻了半天，配置没问题，是我站错了地方。

换成构建，报的是 Not a project root。这条的提示就友好了，直接把出路写给我看：切进含项目文件的那个目录，或者把目录位置当参数告诉它。

站对目录之后一切正常，不到一秒它就回了一句项目检查通过，还附带一个校验号；构建也是不到一秒出一份清单；本地版本库那两条一样读得到，历史看得见。整个过程依然零网络写。

所以那两次拒绝不是命令在为难我，是我站错了位置。你在这儿卡住的话，先别怀疑配置，先看自己在哪个目录。

创建这一步我停在预览，确认键不替任何人按

按惯例，随笔写到这儿该创建我的第一个 agent 了。我没有创建。

不是藏着不说，是这一步本来就该由看完预览的人自己决定。高风险的远端写需要显式确认参数，而确认应该是人做的判断，不是脚本里顺手带上的一个开关。这篇止步预览，落地那一步和销毁那一步我都没跑，全程远端写次数是零。

好处是，这条命令的设计让不创建也能拿到全部信息：

bl managed-agent agent create --name 我的第一个agent --model qwen3.8-max --instructions '回答保持简短。' --dry-run

一秒左右，它回我一个自动生成的配置键名，后面跟着打算创建什么、依赖是否就绪的计划。一件远端资源都没有创建。

少给参数的样子我也试了：只给名字，不给模型和说明，它当场拒绝，还点名缺的是哪两样。不猜、不填默认值，这点比不少命令行工具厚道。

记忆库同理，预览姿势只给键名和计划，不建库。

我现在把这份预览当施工图看：先看清它要建什么、挂在哪些依赖上，看懂了再决定要不要往下走。看不懂就别执行，这句话对托管 agent 尤其成立，因为它建出来的东西会自己动。

两盆冷水：查询不通，账本只是账本

我原本打算装完先列一下，看看家里有什么。这条路在我这个环境不通。

查 agent、查技能、查部署、查会话这四条只读命令我都试了，一律回一个 404；带上工作空间参数再试，也不行。唯一的例外是查 webhook，通了，也确实返回了数据，内容涉及真实资源标识，我不贴。

写这一段是因为先列一下看看这条老经验，在这组命令上不成立，至少在我当前环境不成立。你要是照着别的工具的习惯先跑查询，看到 404 很容易以为是自己装错了，其实是这条路当前不通。我不想编一个漂亮的查询结果糊过去。

另一盆冷水来自账本。什么都没执行过的时候，账本那条命令会明说 No resources tracked in state.

刚看到的时候我愣了一下，后来想明白了：它记的是这台机器上这份配置跟踪了哪些远端资源，是一本本地账本。账本空，不代表云上什么都没有；账本里有，也不代表云上那个还活着。取消跟踪和删除远端是两件不同的事，差别全在这一句里。

想清楚这点，我第二个怕就小了很多。判断云上有没有东西，不能只看本地账本，得两边都对上。

我现在的安全纪律

三段，固定的。

先把预览跑够。检查、变更预览、创建预览这三样想跑几次跑几次，全在本地，不产生远端后果。

然后人来看预览，看完做判断。它会建什么、挂在哪些依赖上、和我以为的是不是一回事，这三问答不上来就不往下走。

确认无误之后，才由我自己带上确认参数去执行那一步。

这篇停在中段。确认键该由看完预览的人自己按，我不替任何人按，也不建议把它写死在脚本里。

一点感受

托管 agent 这类东西，最劝退的其实不是概念多，是我按下去之后会发生什么这个不确定性。这组命令把不确定性挪到了预览里，让我可以先看清楚再决定，这一点对新手的友好程度比我预想的高不少。

如果你也想试，我建议的顺序是：空目录里把本地三步走完，让对错本地就有答案变成肌肉记忆；要管目录项目，先切进目录再跑检查和构建；想创建任何东西，先看预览，看不懂就停；别信先列一下的直觉；被拒绝的时候先读提示，这组命令的提示连替代出路都直接告诉你。

想先在网页上看看托管 agent 长什么样，可以去阿里云百炼控制台逛逛。终端这条路，从安装到看完第一份预览，五分钟，云上一个字节都不会动。

你第一次碰基础设施类的命令时，最怕的是写错配置，还是怕手滑把东西建出来？评论区聊聊，我想知道是不是只有我在这两件事上纠结了这么久。