规避Agent技能固化的流程管理要点

很多团队一听到“把流程做成 Agent 技能”，就兴奋得像捡到了自动化神器：经验不用反复讲，标准不用靠人记，任务交给 Agent 跑就行。可我觉得，真正危险的地方也在这里——流程一旦被固化，错误也可能被稳定、快速、毫不犹豫地重复执行。Agent 技能不是写完就封存的说明书，而应该是一套会随着项目变化持续调整的工作机制。

先固定边界，不要固定所有判断

适合沉淀成技能的，通常是重复度高、验收标准清楚、结果能快速验证的任务，比如批量重构、测试补齐、脚手架搭建和文档同步。这些流程可以明确输入、执行步骤和验收条件，Agent 执行起来更稳定。

但需求澄清、架构取舍、跨团队协调这类工作，往往依赖上下文和临场判断。如果我们急着把它们也写成“标准流程”，最后得到的可能不是效率，而是一台特别勤快的流程复读机。

我的做法是把技能拆成两部分：能自动执行的动作，以及必须由人确认的决策点。这样既不会让 Agent 每一步都等审批，也不会把关键判断悄悄交出去。尤其是会修改代码库、运行命令或接触不同业务资源的技能，更要提前写清权限边界，不能因为“大家本地都能访问”就照搬旧习惯。

给技能设置“退役机制”

技能最容易出现的问题，不是无法运行，而是运行得太顺。项目早期适用的检查项，到了架构调整后可能已经过时；某个团队曾经需要的限制，也可能变成新阶段的额外负担。如果没有复盘入口，Agent 只会把陈旧经验执行得更加高效。

所以每个技能都应该留下几个可观察的问题：它解决的原始问题还存在吗？执行结果是否仍然符合当前架构约束？失败通常发生在哪一步？哪些环节最近总需要人工绕开？这些信号比“技能还能不能跑”更重要。

我不建议一开始就追求全自动。可以先让 Agent 执行边界清晰的部分，同时保留人工审阅；等反馈稳定后再扩大范围。技能的成熟，不是它覆盖的流程越多越好，而是团队知道什么时候该使用、什么时候该暂停、什么时候该重写。真正灵活的流程管理，留下的不是一套永远不变的标准答案，而是让 Agent 和人都能及时修正答案的空间。