把工作区当成 Harness 契约：AGENTS.md、skills、tools.json 各管什么

很多团队把 Agent 配置写进代码常量：系统提示硬编码，工具列表写死在初始化函数，换一个客户就要 fork 一份部署。更可持续的做法，是把「定义」落成工作区文件，让同一套 Harness 逻辑携带不同的人格、技能和工具面。

AgentScope 一类文档把这件事说得很直白：AGENTS.md、skills、tools.json、MEMORY.md 各管一块；文件与 API 等价，但文件天然适合多租户覆盖。

一、先分清四类文件

AGENTS.md：常驻行为。人格、项目约定、禁止事项、输出格式。它几乎每轮都在场，所以要短、要稳、要可审计。

skills/：可复用能力包。每个子目录一份 SKILL.md，必要时带 references 和 scripts。启动只暴露目录，命中再加载。

tools.json：工具白名单与 MCP server。它回答「模型现在被允许看见哪些工具」，不是「模型听说过哪些技能」。

MEMORY.md 与 memory/：跨会话仍成立的事实。进度、偏好、已确认结论。它不是把聊天记录再存一遍。

混放的代价很大：把工具权限写进 AGENTS.md，靠模型自觉遵守；把长期记忆塞进 skill，技能一卸载记忆也没了。

二、为什么「定义写成文件」更像生产

第一，可覆盖。用户级、租户级目录覆盖同一套 agent 逻辑，不必多套代码分支。

第二，可评审。改 AGENTS.md 或 tools.json 能走 PR、diff、回滚，行为变更看得见。

第三，可投影进沙箱。静态资产按内容哈希注入容器，脚本在隔离环境跑，工作区既是配置源也是执行边界。

三、契约怎么落到运行时

AGENTS.md 编译进系统提示或常驻上下文。

skills 编译成「名称 + 描述」清单，真正正文按 load 进入。

tools.json 编译成工具注册表；MCP server 在此声明，不在聊天里临时发明。

MEMORY.md 在压缩后仍保留；完整轨迹另存，不和契约文件抢位置。

一条实用规则：换模型后仍必须保留的约束，写进 AGENTS.md 或 tools.json；仅对某类任务有用的流程，写进 skill。

四、落地时的检查清单

1. AGENTS.md 是否短到人愿意读完，是否包含禁止事项
2. skills 是否只有已验收包，草稿是否隔离
3. tools.json 是否最小权限，写操作是否有审批策略
4. MEMORY.md 是否只记已确认事实，是否可被人手改错
5. 工作区变更是否进 Git，发布前是否能 Dry-run 打印生效配置

五项里有两项答不上来，说明你还在「提示词工程」，还没进入「契约工程」。

结语

Harness 不只是循环代码，它还是一套关于「什么常驻、什么按需、什么允许、什么记住」的边界声明。把工作区当成契约，Agent 才能在多租户、可评审、可回滚的轨道上长大；否则每接一个客户，都像重新发明一次运行时。