技术 · 熟练
你的 agent 换台机器就跑不起来？
因为它的定义活在聊天记录里，不活在一个文件里
一个 agent 真正难搬的从来不是模型，是「它是怎么被设起来的」——模型设置、提示词、挂了哪些工具、跑起来是什么行为、跟别的 agent 什么关系，这些东西如果只散在某个人的聊天记录与本地设置里，换台机器或换个人就等于从头再搭一遍。这一页讲的做法是：把 agent 当可移植的运行单元来做 —— 这些设置全部写进一个声明式文件（YAML 或 HCL），进源码控制、有版本，打包成标准制品分发；运行时再决定接哪家模型、连哪些工具。判断标准只有一条：把你这套 agent 交给同事，他拿到的是什么 —— 一段说明，还是一个能直接跑起来的单元。
方法 · 一图看懂
1
先把设置从聊天里搬进文件 — 模型设置 · 系统提示词 · 工具清单 · 运行时行为 · 多 agent 关系，逐项写进声明式配置
2
让这份文件进版本控制 — 谁改了什么、什么时候改的，看提交记录；⛔ 不靠「我记得上次是这么设的」
3
打包成标准制品分发 — 交付物是一个可分发单元，不是一页搭建说明；同事拉到制品就能跑，不必逐条对着文档配
4
运行时再接模型与工具 — 模型供应商、本地或远端工具、检索资源都在运行时选，⛔ 不写死在配置文件里
原理 · 为什么有效
把 agent 当基础设施而不是当一次配置，解决的是一类反复出现的成本：搭一次的人懂，接手的人不懂。声明式定义的实质是把「这套 agent 是什么」变成一份可读、可比对、可回退的文本 —— 于是它就有了版本、有了差异、有了回滚；而标准制品解决的是一致性：同一份制品在别人机器上跑出来的行为与在你机器上一致，不必逐条核环境。而运行时才绑定模型与工具，是为了让「换一家模型」不触发「重搭一遍 agent」 —— 换供应商改的是运行参数，不是这件产出的定义。
适用场景
适合：你已经在用 agent 干某件固定的事（不止试过一次），并且需要它被别人接手或需要在多台机器上跑出一致行为；或者你想把自己攒的这套 agent 分享出去。也适合团队内部要统一「我们家的 agent 长什么样」——一份制品比一份口头约定可核。⛔ 不适合：还在探索阶段、设置每天在变的 agent（此时代码化只是给未定型的东西加一层手续）；以及只用一次、跑完就丢的一次性任务。
自测 · 5 问
模型名、提示词、工具清单三样都能在配置文件里找到，而不是在某人的设置面板里
配置进了版本控制，能看出上次改了什么
同事拿到的是一个可运行单元，不是一页搭建说明
换一家模型供应商只改运行参数，配置文件的定义不用动
本地模型与远端模型都能接，没有被写死在某一家上
怎么上手 · 验证步骤
从最小的一份开始：挑一个你每天都在用的 agent，把它的模型设置、系统提示词、工具清单三样抄进一个配置文件，先不追求完整。然后做一件检验的事 —— 把这份文件发给你自己，换一台机器照着它跑起来：如果过程中你还需要回忆任何一处没写进文件的设置，那处就是漏项，补回去。跑通之后，再把多 agent 关系与检索资源补进去。
上线前问自己一句：这份配置如果被别人改了，我能从提交记录里看出他改了什么吗？如果答案是不能（比如定义还散在两三个文件里、或者有隐式依赖），先合并到一处再发。