同一位Agent连接了多个账号或空间之后，最让人担心的往往不是“能不能写”，而是“这次会写到哪里”。任务描述没有变，命令也很眼熟，只要实际采用的配置不同，目标就可能和操作者以为的不一样。
这类问题在执行前不一定明显。账号名称相近、旧配置仍然保留、不同入口采用了不同设置，都可能让人凭印象判断当前目标。等到写入之后才检查，纠正的成本就高得多。
因此，多账号使用的重点是让本次执行目标在动手前变得明确。理解参数、配置与环境值怎样共同决定结果，再核对实际账号和空间，才能把“应该是这里”变成可确认的选择。
先理解当前命令从哪里读配置
CLI解析顺序为单项flags、--config、--profile、活动账户.env、默认值。导出的环境变量会覆盖磁盘上的配置；排查时应同时检查命令和进程环境里是否指定了覆盖项，不输出token内容。
auth switch会把选定账户写入共享的~/.busabase/.env。这让读取该文件的Skill、脚本和SDK跟随切换，但两个终端并行时，也不能再把共享活动状态当成各自任务的固定目标。
用--profile为单次命令读取指定账户，不改共享.env；--config可使用独立配置文件。自动化还应明确--base-url与--space-id，使目的地可以从任务本身核对。不要把密钥写进会展示的命令或审计。
把目的地拆成五层
CLI账户说明区分账户与工作区：账户是凭据，一份账户可加入多个Cloud工作区；CLI将工作区称为space，对应--space-id及API的x-busabase-space。自托管服务器报告自己的单一工作区。
一次写入还需要主机、Base和记录。因此目标清单至少包含host、account/profile、Space ID、Base ID以及已有记录ID或新记录的唯一业务键。Folder可用于确认资源归属，表名用于帮助人识别，不代替ID。
同一API token能够访问多个资源时，仍需要明确选择本次目标。凭据证明请求权限，不能单独证明业务对象选对了。
让每个并行任务携带自己的目标
手动使用时，活动账户切换很方便；并行脚本和Agent任务则更适合显式profile或独立config，加上明确主机和Space。一个任务换目标，不应顺手改掉其他任务依赖的共享配置。
先把一条经常运行的写入任务做成完整循环：明确目标、只读对照、限定变更、canonical回读。团队就能从“应该写在这里”走向“证据显示写在这里”。
一次只读预检要确认什么
先用指定配置读取whoami，核对当前身份及工作区；再读取目标Folder、Base的实际归属和schema。已有记录更新，还要读该记录当前值及head，确认它属于该Base且内容符合任务。
建议让Agent返回一份不含秘密的清单：主机、账户别名、身份、Space ID、Folder/Base ID、目标记录和本次允许修改字段。预期值来自人或已批准任务，实际值来自读取结果，不能两个都由Agent临时猜。
出现主机不符、工作区无法访问、Base归属不对、同名多表或记录语义不匹配，就暂停本次写入。不要靠切换到另一张同名表让命令跑通。权限报错也是需要定位的结果，不是尝试其他账户直到成功的理由。
需要委托Agent时，可以这样描述任务
使用指定profile，在明确的base URL和Space ID下只读核验身份、Folder、Base及目标记录。对照任务给定ID，列出匹配与冲突，不显示凭据。确认前不切换共享活动账户，不修改配置，不提交任何变更。
把身份核验带进变更请求
预检通过后，使用同一明确配置提交限定范围的ChangeRequest。将任务、目标资源和修改字段写清楚，更新已有记录时核对当前版本，避免覆盖期间发生的新变化。
记录写入通过ChangeRequest保留变更依据。实际状态由权限和服务端处理决定：写权限可使变更立即合并，其他情形会等待审阅。返回一个CR不表示canonical已经改变，待审也不等于写失败。
任务若要求人审，则按该要求提交并核对状态。不要把“我确认目的地正确”扩张为“内容已经批准”，也不要为验证连接而写一条无关正式记录。
连接测试成功，仍缺哪份目标证据
whoami可以帮助核身份，但业务任务还要核目标Base和记录。把预期ID放在任务里，再读取实际归属；不能从“找得到一张同名表”倒推它就是目的地。字段结构也要核：另一工作区的相似表可能保留相同标题，却服务不同业务。
并行运行时，尽量让profile或独立config成为任务参数，并明确host和Space；共享活动账户更适合人工切换，而不是充当多个任务唯一的目标来源。若确实需要切换共享配置，先确认依赖它的其他运行，再安排切换，不要在写入失败后随机尝试账户。
写后回读，确认实际落点
读取CR真实状态及操作对象，再从指定host、Space和Base回读canonical记录。核对目标字段、记录身份和未授权修改的字段。只看到命令退出码为零，还不足以知道改动落到了何处。
超时后先读原CR及canonical，再决定是否重试；不要直接重建记录。新建任务应保留稳定业务键和原CR，避免在未知结果时重复创建。
可以复用执行任务Base，建议记录目标host、账户别名、Space/Base/record ID、允许字段、原head、CR ID、合并状态与回读结果。清单里不存token。这是建议的审计设计，不是创建表后自动获得隔离保证。