harness enigneering-任务入口窗口-随笔
- 内容介绍
- 文章标签
- 相关推荐
意义：搭建跟自身项目有关的垂直环境。常用的codex，cc等其实本身有通用harness 内核，但我们仍需根据自己的工作场景在此基础上搭建垂直场景的harness 框架，以便于agent能更好完成目标（其实就相当于给一个公司制定工作流程和员工守则）。（4.25 01:38 兴致勃勃）
记录一下第一个最主要的关口：任务入口/窗口
意义：把人类的自然语言转换成agent可执行的完整清单。变成结构化对象json文件。
核心任务：分析界定任务内容，具体可为以下几点：
（1）用户想做什么（intent classification）
（2）任务对象是什么（object）
（3）允许做什么（boundary）
（4）需要读取哪些上下文（context）
（5）要做的事情是否安全，是否有风险（risk）
（6）根据风险等级评估结果是否让人介入审批（approval）
（7）怎么验证结果（validation）
（8）最后展现什么结果，产品（deliverable）
具体分析：
1.intent
agent其实不懂到底人类到底什么意思，它更倾向于用户的请求应该进入哪一条链，哪种工作流。
因此，intent其实就像路由标签和索引一样。可随时认定和引用。
用户请求—intent分类— 选择工作链
因此必须构建完整的intent taxonomy。并且在真实场景中，intent应该分类分层设计，可以从垂直场景的不同状态划分intent类别，也可以分层控制从大类到过程到动作手段。
但如果intent taxonomy过于精细繁重就会导致无法识别，相互影响。所以要研究怎么识别intent taxonomy的方法。
方法有以下几类：
（1）自定义规则分类。直接设定捕捉具体字段，形式之类，简单方便，但复杂度上升梯度大，而且对复杂语义和意会都无法识别。
（2）利用llm结构化分类。就是利用模型帮你识别语义，但还要设定schema规范输出格式（无限套娃，一层层界定）。
（3）对以上两种混合使用。简单意义规则分类，复杂的借助llm，当然，也可以用混杂一些embedding检索，小的模型分析这些，都可以混，最后打分，靠置信度评价给出结果，或者融合结果。
根据这个我们可以获得一个结构化输出结果
分析的意图，置信度，关键词，什么分类器认证的等等所有信息，这样我们就可以完成认证标注了。
除此之外，intent classification应该能识别多意图的能力，因为人往往会提出多个要求，并且任务之间存在先后顺序。可以通过连接词识别，多词态分析比如存在多动词多名词等方式来识别，识别后进行语段切割，子任务切割，主次区分。
此外，审查和澄清也相当重要，由于harness本身要求全流程连贯，提高使用效率。所以agent应该减少和用户交互过程。因此，只应该允许置信度低，intent冲突，high risk，缺少object或者无法明确时，这种应该及时反馈交付用户审查。
另外intent模块也可以自己装配测试集，完成自我验证，增强可信度。
总结一下，intent classification的内容
1.先定义 intent taxonomy
-
用规则识别明显任务
-
用 LLM 处理复杂语义
-
用 Pydantic 或 JSON Schema 固定输出
-
支持多 intent 拆分
-
保留 evidence 和 confidence
-
低置信度或高风险时触发澄清
-
用测试集评估分类效果
最终通过intent classification你可以把用户请求定义到正确的workflow工作链上。
2.object
意义：明确任务作用对象。
比如帮我切个西瓜，西瓜要切成方的，越小越好。
这个就有很多对象，作用对象：西瓜，形状对象：方形，指标对象：大小
agent在得到intent后，应该能具备立刻明确具体操作对象的能力。
如果他不具备这个能力，他就会不知道切什么水果。乱切成芒果，大小形状也无法控制。
在具体的应用场景，object可以分为很多种，目标对象，文件路径对象，环境领域对象，指标对象，数据对象，想调用的工具，禁止更改对象等等，看需求添加。
因此，我们又可以针对这个得到一个结构化输出。
那怎么识别对象呢，跟intent一样，还是规则定义，形式匹配，llm识别。
除此之外还有一个要求就是可以对所提对象之间完成索引锁定，我可以直接明确你说的这个对象在哪个文件定义的，我要找到这种映射关系。这个也是通过文件名匹配，关键词搜索，ast解析类名函数名，embedding检索等等方法完成映射锁定，还是一样的套路。
object还有一个很重要的，就是他能迅速锁定boundary对象，是否有risk，要加载哪些相关的context。
当然，这里提醒一下，无论是intent还是object，用户输入的语义正确很重要，如果用户无法准确输入需求，就很容易导致执行错位，比如你说优化一下，它很难分辨是要从正确率上还是速度还是大小上，因此正确表述需求才能更好的使用ai（文科生的价值也许超乎想象）。
总结一下：
-
领域词典匹配
-
正则/模式匹配
-
LLM 结构化抽取
-
同义词标准化
-
仓库索引
-
ripgrep 搜索
-
AST / tree-sitter 符号索引
-
object → file 映射
object这一步就是在完成锁定操作对象。
3.boundary
agent边界控制。就像人一样，agent也要有自己的边界感，在做事情的时候，什么事能做什么事不能做，什么东西能碰什么不能碰，这个应该明确。boundary可以有效限制agent乱改，越权，污染文件。
当object输出后，boundary应该能根据对象立刻调出以下几点：可动文件或路径，不可动文件或路径，允许与不允许的操作，需要索取approval的操作等等。
就相当于一个目标优化问题求解，pso之类，我先给你锁定一个你可以跑的多维空间，然后你必须在这个空间里面自己寻优，操作。
之外，boundary应该贯穿整个状态：
执行前：决定哪些文件和工具可用
执行中：拦截危险动作
执行后：用 git diff 检查是否越界
boundary在每次运行中应该能接受以下信息，已确定可执行边界。
（1）intent 结果
（2）object结果
（3）项目规则，预案规则（一般用md，yaml之类写好）
（4）git differ返还结果（未提交/已提交）
（5）用户提示词（自主提高优先级）
boundary最后也会生成一个结构化输出，包括之前提到的允许/不允许操作、工具、功能、可改大小，时间限制等
boundary应该能根据不同的输入形成不同的规则模版，并且可以不断迭代更新自身规则，然后生成新边界，当然规则之间直接应有优先级，避免覆盖，遗忘等现象。
总结：
Policy 规则文件
-
路径白名单/黑名单
-
动作权限
-
工具权限
-
命令拦截
-
网络限制
-
资源限制
-
执行后 git diff 审计
有效的boundary应做到识别它能碰什么；不能碰什么；碰之前要不要问你；碰完后怎么检查有没有越界。
4.context
context回答的是Agent 在操作之前，要看什么资料，哪些即刻看，哪些一会看
context需要根据前面得到的 Intent + Object + Boundary 转成一组具体上下文包。
Intent 决定上下文类型
Object 决定相关文件
Boundary 决定可访问范围
例如，intent分类到画图，object指向风景图，这时候context应该能加载绘图脚本，格式规范，可用简易图标等等。
常用context：
-
User Context用户上下文
-
Task Context 任务上下文
-
Conversation Context 对话上下文
-
Product Context 垂直领域上下文
-
Environment Context 环境上下文
-
Tool Context工具上下文
-
Memory Context 记忆上下文
-
Policy / Constraint Context 约束上下文
context输出步骤
-
加载基础规则上下文
-
根据 Intent 选择上下文模板
-
根据 Object 找相关文件
-
根据 Boundary 排除禁止上下文
-
根据优先级和 token 预算排序
-
生成 ContextPlan
同时，上下文不是越多越好，很多人认为上下文多就可以懂得多，分析更全，实际因为关键信息被稀释，过期信息污染判断，模型注意力分散等等，agent会变笨，因此设计Context原则应该是足量不过量。
当上下文量达到一定程度的时候，context必须进行压缩，形成信息或结构摘要，片段检索，滑动窗口记录，或切片选择top5chunk来进行必要压缩，保留主要信息。
上下文检索一般依赖Repo Index ，就像提前画个地图。比如你想找一个淘宝上的的商品，如果没有索引，你要找半天都找不到，有了索引，你就可以直接链接转过去，这样 AI 不用凭感觉找文件，而是能先定位大概位置。
（4.25 05:32力竭了，不想写了，一晚上没睡觉，有时间继续）
除此之外，context还需要给资料排优先级，它必须在巨量的可读上下文中让agent能按必要性读到最需要注意的资料。
上下文不是不变的，上下文应该是实时根据内部文件调整变化的，比如git diff，测试结果修正后，上下文会随之调整。
核心要点：
-
Context 由 Intent、Object、Boundary 共同决定。
-
不是越多越好，而是越相关越好。
-
项目规则优先，任务材料其次，动态反馈持续更新。
-
读上下文也要遵守边界。
-
大文件要摘要，小问题要局部片段。
-
旧信息要降权，新日志和当前 diff 要升权。
-
每个上下文都要有来源、目的和优先级。
-
工具执行结果要回流成新上下文。
因此，context的主要任务是完成在构建思维链之前的相关信息注入。
（我觉得整个任务入口层有点像想达到world model的效果，当然世界模型是直接形成因果链，这个是要通过人工构建一个因果反馈链？）
5.risk
意义：按上述结构输出的目标做，是否存在风险，是否要经过用户审批核验。如何把风险构建成成可计算的等级，以实现拦截，审查等功能。
比如一个界面，如果你说给这个前端界面换一个颜色，agent会直接执行，但如果你要更改这个前端界面对应的功能，那大概率agent要对你询问确定了。因为你会修正破坏代码和业务功能。
risk靠什么判断呢
Intent：任务类型
Object：作用对象
Boundary：允许和禁止范围
Context：项目规则和当前状态
Repo State：git 状态、当前分支、未提交修改
User Constraint：用户临时要求
Tool Plan：Agent 可能调用的工具
这些汇总起来就是你的输入来源，agent会把这个结果分为低中高多档，把不影响项目的放过，死守严重影响项目核心的任务和操作。
主要风险有intent ，object，action ，state几类，前三个比较好理解，第四个一般会因为工作区未提交修改，环境空间不足，无备份，正修正主链条等原因提升当前状态风险。这四个应该是不同的四个正交纬度，一旦哪个纬度到极高风险，应直接跳闸，交付用户审查。或者在高风险的时候是否要引入其他缓解策略，并在完成后进行自检。
实际场景下，agent应该重点检测部分任务字段，比如删除，清理，修改，密钥，权限等敏感字样以安全评估。
常规risk输出应做到以下：
risk level：危险等级
risk reasons：为什么危险
approval mode：能不能直接做
mitigation steps：做之前怎么降低风险
validation strength：做完后怎么证明没出问题
6.approval
前文risk已经评估了这个任务有多危险，要怎么缓解回测，approval要解决的是，就是根据这个结果，考虑是否要直接执行或向用户请求审批或者提权，提权要提多少，是否要一步步确认。
因此approval需要设置几档开关，
1.auto直接执行对于低风险
2.auto with diff 执行但要审查输出git differ结果对于中风险
3.ask before edit高风险必须在修正前询问。
4.manual approval，极高风险每步都审批
5.blocked，直接拒绝（比如？把你设置的api密钥整个泄漏出去？）
approval还有一个关键功能就是可以设置gate，设置门禁，每次调用的时候或者动作的时候都得过门禁看看批准与否。另外approval应该有限定，比如只是这一步同意，只是这个session同意，只是这个task同意。不能同意一次一直开发权限。
另外approval最好记录日志随时可以查阅反思。
总结一下approval功能：
根据风险等级、边界规则和当前状态，
决定 Agent 哪些动作可以自动执行，
哪些动作需要确认，
哪些动作必须禁止，
并记录所有授权过程。
7.validation
意义：在完成任务的时候怎么判断agent是否做对了
validation主要完成六类检验：
boundary validation边界检验
syntax vali语法检验
test vali测试检验（做个smoke test？）
behavior vali行为检测（接口能通吗？）
metric vali指标检测
output vali成品检验，成品？格式？
但每个都六类检测太浪费资源了，所以我们可以通过risk判断的需要验证的强度，来思考到底要几维验证，越高越全。
vali流程如下：
-
读取 TaskSpec
-
根据 Intent 生成基础验证项
-
根据 Risk 增加验证强度
-
根据 Boundary 增加越界检查
-
根据用户目标增加成功标准检查
-
执行每个 check
-
收集证据
-
生成 ValidationReport
-
决定 passed / failed / needs_review
Validation 模块的本质是拿证据说话！
8.deliverable
交付模块，意义：回答要交付什么，什么格式。
交付物应该完成
-
根据 Intent 选择交付模板
-
根据 Risk 增加风险说明和证据要求
-
根据 ValidationReport 填入检查结果
-
根据 ExecutionLog 填入命令和操作
-
根据 GitDiff 填入 changed files 和 diff summary
-
根据用户要求加入指定产物
-
生成最终报告
Deliverable 模块用于将 Agent 执行过程中的结构化信息汇总为标准化交付结果。其输入通常包括 TaskSpec、RiskSpec、ValidationReport、执行日志、工具调用记录、生成文件路径和 git diff 摘要；输出则是面向用户或下游系统的 TaskDeliverable，用于记录任务结果、证据链和最终状态。
从实现上看，Deliverable 通常由模板驱动生成。系统根据 intent 选择基础交付模板，根据 risk_level 增加风险说明、审计信息或回滚建议，再根据 ValidationReport 填充验证结果。如果验证失败，Deliverable 不应输出“完成”，而应标记为 failed_validation 或 needs_review，并附带失败检查项和修复建议。（4.25 08:35马上到站了，写不动了，最后这部分直接oai搜索总结了一下）
不写了，本来是做火车来找对象的，订的硬座睡不着，所以随笔记录一下。
里面都是自己借助ai学习，尝试的一些理解，可能大错特错，哈哈哈。
网友解答：--【壹】--：
感谢佬友的分享，写的非常详细，涨知识了！
--【贰】--：
非常感谢佬友分享，值得细细品读，再次感谢！
意义：搭建跟自身项目有关的垂直环境。常用的codex，cc等其实本身有通用harness 内核，但我们仍需根据自己的工作场景在此基础上搭建垂直场景的harness 框架，以便于agent能更好完成目标（其实就相当于给一个公司制定工作流程和员工守则）。（4.25 01:38 兴致勃勃）
记录一下第一个最主要的关口：任务入口/窗口
意义：把人类的自然语言转换成agent可执行的完整清单。变成结构化对象json文件。
核心任务：分析界定任务内容，具体可为以下几点：
（1）用户想做什么（intent classification）
（2）任务对象是什么（object）
（3）允许做什么（boundary）
（4）需要读取哪些上下文（context）
（5）要做的事情是否安全，是否有风险（risk）
（6）根据风险等级评估结果是否让人介入审批（approval）
（7）怎么验证结果（validation）
（8）最后展现什么结果，产品（deliverable）
具体分析：
1.intent
agent其实不懂到底人类到底什么意思，它更倾向于用户的请求应该进入哪一条链，哪种工作流。
因此，intent其实就像路由标签和索引一样。可随时认定和引用。
用户请求—intent分类— 选择工作链
因此必须构建完整的intent taxonomy。并且在真实场景中，intent应该分类分层设计，可以从垂直场景的不同状态划分intent类别，也可以分层控制从大类到过程到动作手段。
但如果intent taxonomy过于精细繁重就会导致无法识别，相互影响。所以要研究怎么识别intent taxonomy的方法。
方法有以下几类：
（1）自定义规则分类。直接设定捕捉具体字段，形式之类，简单方便，但复杂度上升梯度大，而且对复杂语义和意会都无法识别。
（2）利用llm结构化分类。就是利用模型帮你识别语义，但还要设定schema规范输出格式（无限套娃，一层层界定）。
（3）对以上两种混合使用。简单意义规则分类，复杂的借助llm，当然，也可以用混杂一些embedding检索，小的模型分析这些，都可以混，最后打分，靠置信度评价给出结果，或者融合结果。
根据这个我们可以获得一个结构化输出结果
分析的意图，置信度，关键词，什么分类器认证的等等所有信息，这样我们就可以完成认证标注了。
除此之外，intent classification应该能识别多意图的能力，因为人往往会提出多个要求，并且任务之间存在先后顺序。可以通过连接词识别，多词态分析比如存在多动词多名词等方式来识别，识别后进行语段切割，子任务切割，主次区分。
此外，审查和澄清也相当重要，由于harness本身要求全流程连贯，提高使用效率。所以agent应该减少和用户交互过程。因此，只应该允许置信度低，intent冲突，high risk，缺少object或者无法明确时，这种应该及时反馈交付用户审查。
另外intent模块也可以自己装配测试集，完成自我验证，增强可信度。
总结一下，intent classification的内容
1.先定义 intent taxonomy
-
用规则识别明显任务
-
用 LLM 处理复杂语义
-
用 Pydantic 或 JSON Schema 固定输出
-
支持多 intent 拆分
-
保留 evidence 和 confidence
-
低置信度或高风险时触发澄清
-
用测试集评估分类效果
最终通过intent classification你可以把用户请求定义到正确的workflow工作链上。
2.object
意义：明确任务作用对象。
比如帮我切个西瓜，西瓜要切成方的，越小越好。
这个就有很多对象，作用对象：西瓜，形状对象：方形，指标对象：大小
agent在得到intent后，应该能具备立刻明确具体操作对象的能力。
如果他不具备这个能力，他就会不知道切什么水果。乱切成芒果，大小形状也无法控制。
在具体的应用场景，object可以分为很多种，目标对象，文件路径对象，环境领域对象，指标对象，数据对象，想调用的工具，禁止更改对象等等，看需求添加。
因此，我们又可以针对这个得到一个结构化输出。
那怎么识别对象呢，跟intent一样，还是规则定义，形式匹配，llm识别。
除此之外还有一个要求就是可以对所提对象之间完成索引锁定，我可以直接明确你说的这个对象在哪个文件定义的，我要找到这种映射关系。这个也是通过文件名匹配，关键词搜索，ast解析类名函数名，embedding检索等等方法完成映射锁定，还是一样的套路。
object还有一个很重要的，就是他能迅速锁定boundary对象，是否有risk，要加载哪些相关的context。
当然，这里提醒一下，无论是intent还是object，用户输入的语义正确很重要，如果用户无法准确输入需求，就很容易导致执行错位，比如你说优化一下，它很难分辨是要从正确率上还是速度还是大小上，因此正确表述需求才能更好的使用ai（文科生的价值也许超乎想象）。
总结一下：
-
领域词典匹配
-
正则/模式匹配
-
LLM 结构化抽取
-
同义词标准化
-
仓库索引
-
ripgrep 搜索
-
AST / tree-sitter 符号索引
-
object → file 映射
object这一步就是在完成锁定操作对象。
3.boundary
agent边界控制。就像人一样，agent也要有自己的边界感，在做事情的时候，什么事能做什么事不能做，什么东西能碰什么不能碰，这个应该明确。boundary可以有效限制agent乱改，越权，污染文件。
当object输出后，boundary应该能根据对象立刻调出以下几点：可动文件或路径，不可动文件或路径，允许与不允许的操作，需要索取approval的操作等等。
就相当于一个目标优化问题求解，pso之类，我先给你锁定一个你可以跑的多维空间，然后你必须在这个空间里面自己寻优，操作。
之外，boundary应该贯穿整个状态：
执行前：决定哪些文件和工具可用
执行中：拦截危险动作
执行后：用 git diff 检查是否越界
boundary在每次运行中应该能接受以下信息，已确定可执行边界。
（1）intent 结果
（2）object结果
（3）项目规则，预案规则（一般用md，yaml之类写好）
（4）git differ返还结果（未提交/已提交）
（5）用户提示词（自主提高优先级）
boundary最后也会生成一个结构化输出，包括之前提到的允许/不允许操作、工具、功能、可改大小，时间限制等
boundary应该能根据不同的输入形成不同的规则模版，并且可以不断迭代更新自身规则，然后生成新边界，当然规则之间直接应有优先级，避免覆盖，遗忘等现象。
总结：
Policy 规则文件
-
路径白名单/黑名单
-
动作权限
-
工具权限
-
命令拦截
-
网络限制
-
资源限制
-
执行后 git diff 审计
有效的boundary应做到识别它能碰什么；不能碰什么；碰之前要不要问你；碰完后怎么检查有没有越界。
4.context
context回答的是Agent 在操作之前，要看什么资料，哪些即刻看，哪些一会看
context需要根据前面得到的 Intent + Object + Boundary 转成一组具体上下文包。
Intent 决定上下文类型
Object 决定相关文件
Boundary 决定可访问范围
例如，intent分类到画图，object指向风景图，这时候context应该能加载绘图脚本，格式规范，可用简易图标等等。
常用context：
-
User Context用户上下文
-
Task Context 任务上下文
-
Conversation Context 对话上下文
-
Product Context 垂直领域上下文
-
Environment Context 环境上下文
-
Tool Context工具上下文
-
Memory Context 记忆上下文
-
Policy / Constraint Context 约束上下文
context输出步骤
-
加载基础规则上下文
-
根据 Intent 选择上下文模板
-
根据 Object 找相关文件
-
根据 Boundary 排除禁止上下文
-
根据优先级和 token 预算排序
-
生成 ContextPlan
同时，上下文不是越多越好，很多人认为上下文多就可以懂得多，分析更全，实际因为关键信息被稀释，过期信息污染判断，模型注意力分散等等，agent会变笨，因此设计Context原则应该是足量不过量。
当上下文量达到一定程度的时候，context必须进行压缩，形成信息或结构摘要，片段检索，滑动窗口记录，或切片选择top5chunk来进行必要压缩，保留主要信息。
上下文检索一般依赖Repo Index ，就像提前画个地图。比如你想找一个淘宝上的的商品，如果没有索引，你要找半天都找不到，有了索引，你就可以直接链接转过去，这样 AI 不用凭感觉找文件，而是能先定位大概位置。
（4.25 05:32力竭了，不想写了，一晚上没睡觉，有时间继续）
除此之外，context还需要给资料排优先级，它必须在巨量的可读上下文中让agent能按必要性读到最需要注意的资料。
上下文不是不变的，上下文应该是实时根据内部文件调整变化的，比如git diff，测试结果修正后，上下文会随之调整。
核心要点：
-
Context 由 Intent、Object、Boundary 共同决定。
-
不是越多越好，而是越相关越好。
-
项目规则优先，任务材料其次，动态反馈持续更新。
-
读上下文也要遵守边界。
-
大文件要摘要，小问题要局部片段。
-
旧信息要降权，新日志和当前 diff 要升权。
-
每个上下文都要有来源、目的和优先级。
-
工具执行结果要回流成新上下文。
因此，context的主要任务是完成在构建思维链之前的相关信息注入。
（我觉得整个任务入口层有点像想达到world model的效果，当然世界模型是直接形成因果链，这个是要通过人工构建一个因果反馈链？）
5.risk
意义：按上述结构输出的目标做，是否存在风险，是否要经过用户审批核验。如何把风险构建成成可计算的等级，以实现拦截，审查等功能。
比如一个界面，如果你说给这个前端界面换一个颜色，agent会直接执行，但如果你要更改这个前端界面对应的功能，那大概率agent要对你询问确定了。因为你会修正破坏代码和业务功能。
risk靠什么判断呢
Intent：任务类型
Object：作用对象
Boundary：允许和禁止范围
Context：项目规则和当前状态
Repo State：git 状态、当前分支、未提交修改
User Constraint：用户临时要求
Tool Plan：Agent 可能调用的工具
这些汇总起来就是你的输入来源，agent会把这个结果分为低中高多档，把不影响项目的放过，死守严重影响项目核心的任务和操作。
主要风险有intent ，object，action ，state几类，前三个比较好理解，第四个一般会因为工作区未提交修改，环境空间不足，无备份，正修正主链条等原因提升当前状态风险。这四个应该是不同的四个正交纬度，一旦哪个纬度到极高风险，应直接跳闸，交付用户审查。或者在高风险的时候是否要引入其他缓解策略，并在完成后进行自检。
实际场景下，agent应该重点检测部分任务字段，比如删除，清理，修改，密钥，权限等敏感字样以安全评估。
常规risk输出应做到以下：
risk level：危险等级
risk reasons：为什么危险
approval mode：能不能直接做
mitigation steps：做之前怎么降低风险
validation strength：做完后怎么证明没出问题
6.approval
前文risk已经评估了这个任务有多危险，要怎么缓解回测，approval要解决的是，就是根据这个结果，考虑是否要直接执行或向用户请求审批或者提权，提权要提多少，是否要一步步确认。
因此approval需要设置几档开关，
1.auto直接执行对于低风险
2.auto with diff 执行但要审查输出git differ结果对于中风险
3.ask before edit高风险必须在修正前询问。
4.manual approval，极高风险每步都审批
5.blocked，直接拒绝（比如？把你设置的api密钥整个泄漏出去？）
approval还有一个关键功能就是可以设置gate，设置门禁，每次调用的时候或者动作的时候都得过门禁看看批准与否。另外approval应该有限定，比如只是这一步同意，只是这个session同意，只是这个task同意。不能同意一次一直开发权限。
另外approval最好记录日志随时可以查阅反思。
总结一下approval功能：
根据风险等级、边界规则和当前状态，
决定 Agent 哪些动作可以自动执行，
哪些动作需要确认，
哪些动作必须禁止，
并记录所有授权过程。
7.validation
意义：在完成任务的时候怎么判断agent是否做对了
validation主要完成六类检验：
boundary validation边界检验
syntax vali语法检验
test vali测试检验（做个smoke test？）
behavior vali行为检测（接口能通吗？）
metric vali指标检测
output vali成品检验，成品？格式？
但每个都六类检测太浪费资源了，所以我们可以通过risk判断的需要验证的强度，来思考到底要几维验证，越高越全。
vali流程如下：
-
读取 TaskSpec
-
根据 Intent 生成基础验证项
-
根据 Risk 增加验证强度
-
根据 Boundary 增加越界检查
-
根据用户目标增加成功标准检查
-
执行每个 check
-
收集证据
-
生成 ValidationReport
-
决定 passed / failed / needs_review
Validation 模块的本质是拿证据说话！
8.deliverable
交付模块，意义：回答要交付什么，什么格式。
交付物应该完成
-
根据 Intent 选择交付模板
-
根据 Risk 增加风险说明和证据要求
-
根据 ValidationReport 填入检查结果
-
根据 ExecutionLog 填入命令和操作
-
根据 GitDiff 填入 changed files 和 diff summary
-
根据用户要求加入指定产物
-
生成最终报告
Deliverable 模块用于将 Agent 执行过程中的结构化信息汇总为标准化交付结果。其输入通常包括 TaskSpec、RiskSpec、ValidationReport、执行日志、工具调用记录、生成文件路径和 git diff 摘要；输出则是面向用户或下游系统的 TaskDeliverable，用于记录任务结果、证据链和最终状态。
从实现上看，Deliverable 通常由模板驱动生成。系统根据 intent 选择基础交付模板，根据 risk_level 增加风险说明、审计信息或回滚建议，再根据 ValidationReport 填充验证结果。如果验证失败，Deliverable 不应输出“完成”，而应标记为 failed_validation 或 needs_review，并附带失败检查项和修复建议。（4.25 08:35马上到站了，写不动了，最后这部分直接oai搜索总结了一下）
不写了，本来是做火车来找对象的，订的硬座睡不着，所以随笔记录一下。
里面都是自己借助ai学习，尝试的一些理解，可能大错特错，哈哈哈。
网友解答：--【壹】--：
感谢佬友的分享，写的非常详细，涨知识了！
--【贰】--：
非常感谢佬友分享，值得细细品读，再次感谢！