如何评估 agent workflow：轨迹、成本和恢复
把 trajectory evaluation、goal-level cost、semantic recovery 和 confidence calibration 放进同一套 agent 评估框架。
ai-engineering
20 篇公开内容使用了「ai-engineering」这个标签。
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 纳入供应链治理。
为什么 Codex 应该是 worker，而不是 scheduler
解释为什么 Codex 等 AI coding 工具应该被约束为一次性 worker，而不是长期调度器或发布控制器。
给 AI 一包该看的上下文，而不是让它乱翻全仓库
说明 AI 执行任务时为什么需要受控上下文包：只给它该看的来源、规则和真相边界，而不是让它在全仓库里随机搜索。
Evidence Contract：AI 交付必须带证据
说明 AI 交付不能只说已经完成，而必须附带可复核证据、验证结果、风险说明、人工决策入口和可追责路径。
Evidence Gate：为什么 AI PR 必须交付证据包
说明 AI PR 为什么不能只交付代码，还必须附上测试结果、截图、日志、风险边界和可复核的证据包，而不是只看 diff。
从一次失败到项目记忆：让流水线自己变得更强
说明如何把一次 AI 失败转化为项目记忆：更新规则、测试、检查清单和上下文包，让流水线持续变强，而不是停留在聊天纠错。
用 label、branch 和 comment 组成 AI 工程状态机
说明如何用 GitHub label、branch 和 comment 组成可审计的 AI 工程状态机。
人应该站在风险边界，而不是只在最后点确认
说明 human-in-the-loop 不应只是最后确认，而应站在需求、风险、发布和回滚等关键边界上。
把 AI 放进隔离执行区：分阶段 worker 才能进入真实项目
说明真实项目中 AI 不应直接修改主工作区，而应在隔离空间执行，并通过阶段门、证据和人工检查进入主线。
Issue 不是 Todo：它应该是 AI 可执行合同
解释为什么 GitHub issue 应该成为 AI coding worker 的可执行合同，而不只是待办标题。
从私有生产经验提炼可开源的 Issue-Driven Agent Workbench
说明如何从私有生产经验中安全提炼公开方法论、模板和 toy example，而不是直接开源私有脚本。
PR merged 不是 done：AI 工程里的发布边界
解释为什么 PR merged 不等于 done，以及 AI 工程流程中 release boundary 应该如何保留。
AI 不是流程本身：什么是项目专用 AI 交付流水线
很多人使用 AI 写代码时，会把整个流程放进一个聊天窗口：描述需求，让 AI 读仓库、改代码、跑测试、总结结果。
从聊天需求到任务合同：AI 执行前必须先分流
说明 AI 开发任务为什么要先从聊天需求转成任务合同，并根据成熟度、风险和证据要求选择执行模式，再进入写代码。
从 triage 到 implement：AI 修复任务为什么要分阶段
解释为什么 AI 修复任务需要 triage、analysis、implementation 和 evidence 等阶段门禁。