阅读量 ，评论量
背景
为agent设计环境，而不是协同工作。
前序知识
agent工作框架
“感知 → 决策 → 行动 → 反馈 → 再感知”
的闭环系统。核心关注两个维度：
- 反馈闭环关注”单次任务做完之后怎么知道结果”；
- 可治理关注”整套系统长期能不能稳定、可控、不持续熵增”；
Perceive
核心：是否有把关键上下文以agent能消费的&冗余信息更少的方式暴露出来。
Decide
核心：任务拆解与plan能力。（graphrag或者基座本身能力提升，个人倾向于持续进化的graphrag）
实际操作时比较重要的是决策约束，知识库约束不住的，就要逐步升级成规则，以代码生成为例：
- 知识库管不住 → 升级成 lint
- lint 管不住 → 升级成类型约束
- 类型系统管不住 → 升级成结构测试 / CI 门禁
同样，信任边界也不应该模糊存在，最好显式定义，而非概率预估：
- 什么任务可以自主完成
- 什么任务只能半自动
- 什么任务必须人工把关
- 遇到哪些情况必须升级给人
- 某类任务出问题后如何回退到更保守模式
Act
核心：适配LLM的完善的工程生态。
Feedback
核心：结果的回流。
- 可观测的执行结果、可明确验证对错的目标、人工介入反馈的倾向/知识等等可以回流给agent，且保证agent能够非常强地注意到这些feedback
Harness
Harness本身需要演化，以应对模型能力、任务类型、系统规模、风险边界这些因素后续变化的可能。一个成熟的Harness设计需要包含：
- Harness 关键设计的变更记录
- 为什么这样设计的说明
- 模型升级后的同步审视
- 对旧规则和旧流程的淘汰机制