AI Agent 运行治理
说明 AI agent 从能执行任务到可放进组织流程之间需要的治理层：权限、证据、工具、轨迹、成本和人工门禁。
带着实践偏向的长文思考。
关于软件、AI、产品判断、个人系统，以及公开成果背后工作过程的文章和备忘。
系列
先从路线开始
先选和当前问题最接近的一条路线，再按顺序读相关内容。
Obsidian + Codex 联邦知识库
解释为什么聊天记录不能承担长期知识库，以及如何把 Obsidian、本地 Markdown、Codex、项目目录和发布节点组织成联邦知识系统。
SketchUp Agent Harness 技术架构
解释为什么 Codex 和 Claude 只是入口，SAH 的核心在 MCP server、project workspace、bridge trace 和 SketchUp bridge。
- 00SketchUp Agent Harness 技术架构：为什么 agent CLI 只是入口
- 01MCP Server 到 Ruby Bridge：把自然语言变成可执行 SketchUp 操作
- 02`design_model.json` 为什么必须站在 SketchUp scene 前面
- 03Bridge Trace：为什么先计划执行轨迹，再调用 SketchUp
- 04让导入可修复：从 source evidence 到 working truth
- 05Runtime Skills 的产品边界：设计师 skill、动态 skill、开发 skill 不应混在一起
- 06Headless Smoke、Live Bridge 和 Installed Package：agent harness 怎么验证
- 07Semantic Component Registry：让 agent 放置对象，而不是搜索模型素材
项目专用 AI 交付流水线
很多人使用 AI 写代码时，会把整个流程放进一个聊天窗口：描述需求，让 AI 读仓库、改代码、跑测试、总结结果。
用 GitHub Issue 驱动 AI 工程协作
解释为什么 GitHub issue 应该成为 AI coding worker 的可执行合同，而不只是待办标题。
AI 设计师工作台
解释面向设计师的 AI 工具为什么应该成为可持续工作台：管理目标、项目状态、反馈和版本，而不是停留在聊天、生成图或自动绘图。
AI 设计工具为什么需要唯一真相源
一个开源早期项目：用自然语言、MCP server、SketchUp Ruby bridge、结构化设计模型和运行时技能，把设计师意图转成可验证、可执行、可修复的 SketchUp 项目状态。
如何评估 agent workflow：轨迹、成本和恢复
把 trajectory evaluation、goal-level cost、semantic recovery 和 confidence calibration 放进同一套 agent 评估框架。
AI Agent 运行治理：把能干活的模型放进真实流程
说明 AI agent 从能执行任务到可放进组织流程之间需要的治理层：权限、证据、工具、轨迹、成本和人工门禁。
多轮 agent 为什么会漂移：从记忆到承诺跟踪
解释 long-running agent session 的 residual drift：系统没有显式矛盾也可能偏离早先承诺，因此需要 commitment tracking。
证据和来源权威：不要让流畅文本压过硬数据
梳理 evidence-carrying action 与 source authority：当用户文本、结构化数据和工具输出冲突时，AI workflow 应如何判定证据优先级。
运行时权限和自治门禁：agent 什么时候该停下来
解释为什么 agent 不能只依赖计划阶段许可，关键动作必须在运行时重新检查权限，并通过 autonomy gate 决定执行、询问或停止。
工具注册表也是控制面：agent tool governance
说明 MCP、插件、工具描述和依赖包为什么都是 agent 控制面的一部分，以及如何把 tool registry 纳入供应链治理。
AI 不是先让你失业，而是先拿走你的执行层
从 NYT 关于 AI 与 permanent underclass 的讨论出发，解释为什么普通人的风险可能先表现为执行层被压缩、入门岗位变窄和工作流位置上移。
我，真快失业了：AI 对普通人的冲击不是 8 年以后
从一次真实的 issue-driven AI 交付经历出发，解释为什么 AI 对普通人的冲击可能不是 8 到 10 年后的远景，而是已经进入 3 到 5 年的窗口。
中央知识库、项目目录、发布节点分别负责什么
说明中央知识库、项目目录和发布节点各自负责什么，为什么单一 vault 模板不足以治理项目事实、长期知识和公开发布。
我为什么不用聊天记录管理知识，而要搭一个本地联邦知识库
解释为什么聊天记录不能承担长期知识库，以及如何把 Obsidian、本地 Markdown、Codex、项目目录和发布节点组织成联邦知识系统。
Obsidian 在这套系统里到底负责什么
解释 Obsidian 在 AI 知识库中的真实职责：提供本地 Markdown、链接、反向链接和人工审阅界面，而不是自动真相机器。
这套系统的边界：隐私、项目真相源、发布审计和失败模式
总结联邦知识库的边界和失败模式，包括隐私、项目真相源、过早自动化、站点霸占真相源和 AI 生成内容误作证据。
为什么项目 AI 不应该默认看到完整知识库
解释为什么项目 AI 不应该默认读取完整中央知识库，以及如何用本地事实优先、窄接口和选择性记忆降低误用风险。
AI 设计师工作台：设计师应该如何和 AI 协作
解释面向设计师的 AI 工具为什么应该成为可持续工作台：管理目标、项目状态、反馈和版本，而不是停留在聊天、生成图或自动绘图。
Bridge Trace：为什么先计划执行轨迹，再调用 SketchUp
解释为什么 live SketchUp 执行前需要可检查、可测试、可回放的 bridge trace。
Codex 如何驱动 SketchUp 建模：从指令到可验证模型
解释 Codex 或其他 agent CLI 如何通过 runtime skills、MCP server、SketchUp Ruby bridge 和结构化设计模型，把自然语言意图转成可验证的 SketchUp 项目状态。
为什么 Codex 应该是 worker，而不是 scheduler
解释为什么 Codex 等 AI coding 工具应该被约束为一次性 worker，而不是长期调度器或发布控制器。
给 AI 一包该看的上下文，而不是让它乱翻全仓库
说明 AI 执行任务时为什么需要受控上下文包：只给它该看的来源、规则和真相边界，而不是让它在全仓库里随机搜索。
`design_model.json` 为什么必须站在 SketchUp scene 前面
解释为什么 SketchUp scene 是执行视图，而结构化 design model 才适合 agent 推理、验证、修复和回放。
设计师的核心价值不是画得更快，而是判断和取舍
讨论 AI 时代设计师的核心价值如何从低层画图执行，转向目标判断、约束取舍、反馈解释、版本决策和可持续协作。
设计师应该专注于想法，而不是成为画图执行者
以 AI 设计工具和 SketchUp Agent Harness 为例，讨论为什么 AI 应该减少低层绘图执行，让设计师把精力放在意图、判断、约束和取舍上。
Evidence Contract：AI 交付必须带证据
说明 AI 交付不能只说已经完成，而必须附带可复核证据、验证结果、风险说明、人工决策入口和可追责路径。
Evidence Gate：为什么 AI PR 必须交付证据包
说明 AI PR 为什么不能只交付代码，还必须附上测试结果、截图、日志、风险边界和可复核的证据包，而不是只看 diff。
从一次失败到项目记忆：让流水线自己变得更强
说明如何把一次 AI 失败转化为项目记忆：更新规则、测试、检查清单和上下文包，让流水线持续变强，而不是停留在聊天纠错。
从聊天建议到可持续设计项目
解释为什么 AI 设计协作需要项目目录、结构化真相、可恢复状态和版本记录，而不是只依赖一段聊天建议。
用 label、branch 和 comment 组成 AI 工程状态机
说明如何用 GitHub label、branch 和 comment 组成可审计的 AI 工程状态机。
Headless Smoke、Live Bridge 和 Installed Package：agent harness 怎么验证
解释为什么 agent harness 需要 headless smoke、live bridge、release smoke 和 installed package 验证。
人应该站在风险边界，而不是只在最后点确认
说明 human-in-the-loop 不应只是最后确认，而应站在需求、风险、发布和回滚等关键边界上。
把 AI 放进隔离执行区：分阶段 worker 才能进入真实项目
说明真实项目中 AI 不应直接修改主工作区，而应在隔离空间执行，并通过阶段门、证据和人工检查进入主线。
Issue 不是 Todo：它应该是 AI 可执行合同
解释为什么 GitHub issue 应该成为 AI coding worker 的可执行合同，而不只是待办标题。
MCP Server 到 Ruby Bridge：把自然语言变成可执行 SketchUp 操作
解释 MCP server、execution trace、JSON-RPC、Ruby bridge 和 execution feedback 如何把自然语言变成可执行操作。
从私有生产经验提炼可开源的 Issue-Driven Agent Workbench
说明如何从私有生产经验中安全提炼公开方法论、模板和 toy example，而不是直接开源私有脚本。
PR merged 不是 done：AI 工程里的发布边界
解释为什么 PR merged 不等于 done，以及 AI 工程流程中 release boundary 应该如何保留。
AI 不是流程本身：什么是项目专用 AI 交付流水线
很多人使用 AI 写代码时，会把整个流程放进一个聊天窗口：描述需求，让 AI 读仓库、改代码、跑测试、总结结果。
让导入可修复：从 source evidence 到 working truth
解释为什么图纸导入应保留来源证据、生成可修复 working truth，并把识别不确定性纳入后续人工修正流程。
Runtime Skills 的产品边界：设计师 skill、动态 skill、开发 skill 不应混在一起
解释 product runtime skills、project dynamic skills 和 maintainer development skills 的产品边界。
Semantic Component Registry：让 agent 放置对象，而不是搜索模型素材
解释为什么 SketchUp agent 需要语义组件 registry，暴露对象用途、放置约束和复用规则，而不只是搜索 3D 模型素材。
SketchUp Agent Harness 技术架构：为什么 agent CLI 只是入口
解释为什么 Codex 和 Claude 只是入口，SAH 的核心在 MCP server、project workspace、bridge trace 和 SketchUp bridge。
从聊天需求到任务合同：AI 执行前必须先分流
说明 AI 开发任务为什么要先从聊天需求转成任务合同，并根据成熟度、风险和证据要求选择执行模式，再进入写代码。
从 triage 到 implement：AI 修复任务为什么要分阶段
解释为什么 AI 修复任务需要 triage、analysis、implementation 和 evidence 等阶段门禁。
视觉反馈如何变成结构化修改
说明截图、渲染和顶视图如何变成结构化修改请求，进入可追踪的设计迭代，而不是堆积成新的意见垃圾，并形成可复用证据。
为什么 AI 设计工具需要唯一真相源
以 SketchUp Agent Harness 为例，解释为什么 AI 设计工具不能只追求看起来画出来了，而需要可编辑、可校验、可修复、可回放的结构化真相源。