项目地址：https://github.com/AdvancingTitans/agent-engineering-toolkit

我第一次认真思考 Agent 的“成长”问题，并不是因为它不会写代码，而是因为它总在重复犯一些已经纠正过的错误。

有一次，我让编码 Agent 修改一个项目。功能完成得很快，单元测试也通过了，Agent 最后给出了一段看起来很完整的总结：改了哪些文件、执行了什么命令、测试结果如何、为什么可以交付。单看这段回答，几乎挑不出问题。

可等我真正检查仓库时，却发现事情没有那么简单。它声称执行过的验证命令，未必留下了可核实的运行记录；测试报告虽然存在，却可能是上一次运行留下来的；代码改动超出了最初约定的目录；项目里的某条开发规则已经过时，但 Agent 仍然在机械遵守；更麻烦的是，这些问题并不是第一次发生。

这时你会意识到，AI 编程里真正难解决的，往往不是“Agent 能不能完成任务”，而是另外两个问题：

我们凭什么相信它已经完成了任务？

以及：

当同一种失败反复发生时，系统能不能真正从中学会什么？

前一个问题属于审计和交付，后一个问题属于训练和演进。现在的大多数工具通常只解决其中一部分：编码 Agent 负责执行，CI 负责测试，扫描器负责检查，Prompt 或 Skill 负责约束行为，评测框架负责打分，观测平台负责保存运行记录。

这些工具都很重要，但它们通常彼此分离。一次真实任务失败了，失败信息可能存在于终端日志里，整改意见可能存在于 Pull Request 评论里，规则可能写在另一个 Markdown 文件里。最后往往还是由人判断：要不要修改 Prompt？要不要补一条 Skill 规则？要不要更新审计规则？改完以后是否真的比原来更好？

Agent Engineering Toolkit，也就是 AET，尝试解决的正是这些环节之间的断裂。

它并不打算替代 Codex、Claude Code 或其他编码 Agent，也不打算替代测试、CI 和安全扫描器。它更像是放在这些工具之间的一层本地工程控制平面：一边记录这次 Agent 工作究竟发生了什么，另一边把反复出现的失败转化为受约束的训练输入，用来改进真正影响 Agent 行为和项目治理的资产。

最小能力面概览：

你要确认什么？	命令	产物
指令、本地引用和 Skill 是否可用？	aet audit	Markdown / JSON / SARIF finding、RulePack identity、证据与 remediation；可选 Profile 和 Candidate Shadow。
diff 是否在人工批准边界内？	aet review	Intent、路径预算、proof 声明与可选更严格 Review Policy。
显式命令是否运行并生成已声明报告？	aet trace -- <argv>	脱敏执行记录、本轮新鲜 Artifact 与可选安全 Validator 结果。
如何随 handoff 或 release 交付证据？	aet evidence pack	Portable Evidence Pack 与静态 Viewer。
审查/测试后工作区是否过期？	aet run	可选的 append-only 交付生命周期。
哪些 Context 与决策有本地来源？	aet context、aet decision	哈希绑定的 Context Manifest 与 Decision Ledger。
仓库为什么这样演进？	aet evolve	可引用的本地/显式远端演进报告。
现有 finding 应先修哪个？	aet triage	默认或 Policy 驱动的可解释排序；绝不改变 finding 原状态。
重复证据问题能否安全改进受限资产？	aet learn	Evidence Only 经验、目标专属候选与 Gate、可选 Shadow、staged 副本。

这里最关键的词不是“自动”，而是可训练。

一套 Skill 能被修改，不等于一个工程系统具有可训练性

现在很多项目都会谈 Skill 优化、Prompt 优化或者规则自进化。常见流程是收集一些任务结果，根据评分修改 Skill，再用一组任务重新评测。

这种思路是有价值的，但它有一个天然边界：优化对象往往只有某一个 Skill 文件，或者某一类提示词。

真实工程项目并不是只靠 Skill 运转的。

一个 Agent 能不能稳定完成工作，往往同时受多种资产影响：Skill 决定它应该如何行动，审计规则决定哪些问题会被发现，审计 Profile 决定不同仓库应该采用多严格的检查，Review Policy 决定哪些路径敏感、哪些证明不可缺少，Trace Validator 决定测试报告或覆盖率文件是否真的满足要求，Triage Policy 则决定大量发现应该如何排序。

如果系统只能训练 Skill，那么它实际只能改进整个工程链条中的一环。

例如，一次失败可能并不是 Agent 不知道应该怎么做，而是审计规则漏掉了问题。此时继续修改 Skill，可能没有任何意义。另一次失败也许不是 Skill 或审计规则的问题，而是 Review Policy 没有要求关键目录必须提供测试证明。还有一种情况是，测试命令确实执行了，但验证器没有确认报告是否由这一次运行新鲜生成，于是旧报告被误当成了新证据。

真正具备训练能力的系统，首先要能区分：这一次失败究竟应该反馈到哪一种工程资产上。

AET 目前注册了六类可以受约束演进的目标，包括 Skill、Audit Rule、Audit Profile、Review Policy、Trace Validator 和 Triage Policy。它并不是把这些资产当成六套彼此孤立的功能，而是通过统一的目标分类、候选生成、目标专用评估、Gate、Stage 和 Adopt 流程，将它们纳入同一个演进框架。

这正是 AET 相比只优化某个 Skill 文档的方案更值得注意的地方。

它训练的不是一段提示词，而是影响整个 Agent 工程过程的一组治理资产。

可以把它想象成一所学校。Skill 类似于给学生的操作手册，Audit Rule 类似于老师的检查标准，Review Policy 类似于考试纪律，Trace Validator 类似于验证答题过程是否真实有效的监考规则，Triage Policy 则决定错题应该先订正哪一类。

如果学生反复犯错，只修改教材并不一定有效。有时应该修改检查标准，有时应该加强考试要求，有时应该改进验证方法。AET 的目标，是让系统能够根据证据判断需要调整哪一部分，而不是遇到所有问题都往 Skill 里再加一句话。

AET 的证据优先，不是多保存一些日志

“证据”这个词在 AI 工具里并不少见，但不同系统对证据的理解差别很大。

很多时候，所谓证据只是 Agent 自己生成的一段总结：“我已经运行测试，所有测试均已通过。”这本质上仍然是自我报告。Agent 说自己做过什么，并不能证明它真的做过。

另一种常见做法是完整保存聊天记录、Shell 输出和模型调用日志。这确实能保留更多信息，但也会带来新的问题：数据量巨大、隐私和密钥容易泄露、不同任务难以比较，而且原始记录里混合了大量无关内容，后续训练时很难判断哪些内容是真正可靠的事实。

AET 采取的是更克制的路线。它默认关注结构化、含义狭窄、可以核验的工程事实，例如 Agent 当时可以看到哪些指令、人工批准的改动边界是什么、明确执行了哪条命令、命令的退出状态是什么、生成了哪个声明过的产物、产物是否与当前工作区仍然匹配，以及哪些内容依然无法确认。

它明确区分 PASS、FAIL 和 UNKNOWN。无法验证的事情不会因为“看起来大概率没问题”而折算成通过。自然语言回答也不能替代真实命令、产物、快照或者明确的未知状态。

这种设计看起来有些保守，却非常符合真实工程的逻辑。

假设 Agent 昨天下午运行了测试，生成了一份 JUnit 报告。今天上午它又修改了核心代码，但没有重新执行测试。很多系统只会看到“存在一份通过的测试报告”，然后把这次交付标记为成功。

AET 会把两个事实分开记录：测试命令当时成功了，但工作区后来发生了变化，因此这份证明已经陈旧。成功与新鲜度不是同一件事。

这就是证据优先真正有价值的地方。它不是为了让报告显得更专业，而是为了防止系统用模糊的置信度覆盖掉实际的验证缺口。

对于开发者来说，这意味着交付时不必只看 Agent 的总结，而是可以看到一张更接近工程收据的记录：批准了什么范围、实际修改了什么、运行了什么、产生了什么、现在是否仍然有效、还有哪些未知项。

最有价值的闭环，是同一份证据既用于交付，也用于改进

AET 还有一个很容易被低估的优势：它没有为“审计”和“学习”各自发明一套互不相干的数据体系。

通常，交付审计产生一套报告，模型训练又需要重新构造另一套数据。前者是为了证明这次任务是否可信，后者是为了优化未来表现。两个系统的数据结构、语义和判断标准往往并不一致。

AET 尝试用同一个 Evidence Plane 同时服务这两个环节。

在交付阶段，audit 用来检查指令、引用和 Skill 是否可用；review 用来判断代码差异是否落在人类批准的范围内；trace 只执行 – 后明确给出的命令，并记录结果和声明产物；context、decision 和 evolve 则记录上下文、决策和仓库历史。最终，这些信息可以被打包为可携带的 Evidence Pack，用于交付、复核或发布。

当某类失败反复出现时，同一批结构化证据又可以进入学习流程：先采集经验，再检查和挖掘模式，随后判断问题对应哪一种目标资产，生成受约束的候选版本，使用目标专用评估器回放基线和候选，经过独立 Gate 后暂存，最后由人决定是否采纳。

这带来一个非常重要的变化：训练不再主要依赖人为编造的抽象案例，而可以来自真实交付中已经发生过的问题。

例如，一个团队连续遇到 Agent 修改超出批准目录的问题。传统做法可能是在 Skill 里加一句“不要修改无关文件”。但 AET 可以先保留每次任务的 Intent Contract、实际 Diff 和 Review 结果，从中确认问题确实重复出现，再决定应该改进 Skill，还是应该收紧 Review Policy 中的敏感路径和证明要求。

又例如，审计长期漏掉某种 package.json 配置缺失。这个问题不应继续堆进 Agent 的提示词，而应该被记录为 Audit Rule 的假阴性反馈，构造最小可复现 fixture，再生成一个声明式规则候选，分别经过核心、验证、留出和对抗任务测试。

这里的价值并不是系统会“自己改规则”，而是它让真实工程反馈有机会进入一个可追踪的改进流程。

从某种意义上说，AET 把过去散落在 Issue、PR 评论、终端输出和开发者记忆里的经验，变成了一种可以训练治理资产的数据。

统一 Adapter 的意义，不只是代码复用

把多种资产接入一个 Adapter 或目标注册体系，表面上看是一种架构抽象，但它真正解决的是演进系统最容易失控的问题：不同资产必须拥有统一流程，同时又不能共用同一种评估方式。

Skill 和 Audit Rule 都可以演进，但它们不能用同一套标准判断好坏。

Skill 改动是否有效，最终关心的是 Agent 行为有没有改善。因此 AET 对 Skill 支持静态契约检查，也支持显式启用 Codex 或 Claude Code 等真实 Host 的基线与候选配对回放。

Audit Rule 的目标完全不同。它需要判断误报、漏报、定位、严重性、确定性和运行时间是否发生回归，因此采用确定性 fixture 分区测试。即使 fixture 全部通过，Audit Rule 也不能立即进入正式规则集，还需要在真实仓库中以 Shadow 模式并行运行。Shadow 结果不会影响正式审计结论和退出码，只用于积累候选规则在现实项目中的比较证据。当前仓库规定，规则采纳还需要达到跨仓库、跨日期的确认门槛，并且新增发现全部得到确认、已确认误报为零。

Review Policy、Audit Profile、Trace Validator 和 Triage Policy 又各有自己的边界。例如，Audit Profile 的候选不能关闭规则或降低严重级别；Review Policy 可以增加敏感路径和证明要求，却不能移除它们；Triage Policy 只能改变排序，不能隐藏发现或改写原始状态；Trace Validator 只能使用安全的 JUnit、SARIF、覆盖率或 JSON 断言，不能生成任意 Python 或 Shell 代码。

Target	候选边界	Evaluator 与采用边界
skill	只改命名 editable block	静态合同或显式启用的 Scripted/Codex/Claude Code 配对 rollout；只有它评估 Agent 行为。
audit-rule	固定 detector allowlist 上的非可执行 RulePack	70 个分区任务、22 个复用 fixture；还需 20 runs / 5 repos / 3 dates 的候选绑定 Shadow。
audit-profile	严重性、敏感路径和已预先批准的 exclusion	不能禁用规则、降低 severity 或通过演进新增 exclusion。
review-policy	只能增加敏感路径和 proof 要求、收紧预算	不替代 Intent Contract。
trace-validator	JUnit/SARIF/coverage/JSON 安全断言	只能验证 Trace 本轮新建或变更、且显式声明的 artifact。
triage-policy	权重和 critical path	只能改排序，不能隐藏 finding 或改状态。

因此，Adapter 的真正意义不是“所有资产都调用同一个接口”，而是实现一种更成熟的统一：

上层流程统一，底层证据和评估保持目标专用。

所有资产都遵循“证据—候选—评估—Gate—暂存—人工采纳”的生命周期，但每一种资产都由适合自己的评估器判断。AET 没有用一个通用 LLM Judge 给所有候选打分，也没有把不同类型的风险压缩成一个看似精确的总分。

这比简单建立一个通用“自我改进 Agent”更克制，也更符合工程现实。因为一个很会评价 Prompt 的模型，并不天然有资格判断安全扫描规则是否产生了误报；同样，代码 fixture 全部通过，也不能证明一个 Skill 真的改变了 Agent 在真实工具环境中的行为。

它不是让候选自己出题、自己答题、再宣布自己进步

许多自进化系统最容易受到质疑的地方，是候选方案同时影响评估标准。

模型发现了一类失败，修改自己的 Prompt，然后又使用自己参与生成的测试案例证明新 Prompt 更好。这种流程很容易产生“训练集表现提升”，却不能说明真实能力提升。

AET 为此引入了 Evolution Constitution。候选不能改变证据状态的含义，不能修改评估器，不能接触或改变留出数据，也不能取消人工采纳要求。候选的修改范围受到基线哈希、可编辑区域和 Patch IR 约束，评估由候选权限之外的组件完成。

这很像把运动员和裁判分开。

运动员可以调整训练方法，但不能改比赛规则；可以改自己的动作，却不能重写计时器；可以在训练场上表现优秀，但正式入选仍然需要独立测试和教练确认。

这种权限隔离，是 AET“可训练性”真正可信的基础。否则所谓自进化，很容易变成候选资产不断修改自己的评分标准，最终获得越来越漂亮、却越来越缺乏意义的指标。

AET 的 Gate 也不会只给出一个“可信度 92 分”之类的综合数字，而是保留多个指标维度。不可变区域被修改、目标哈希不匹配、验证集与留出集重叠、候选自身审计失败、出现能力回归、突破 Token 或命令面预算、增加不必要工作流调用，都会分别导致拒绝或不确定。

这让开发者看到的不只是“候选是否通过”，还包括为什么通过、为什么失败，以及失败应当成为下一轮演进的什么约束。

真实 Host 回放，让“文本变好了”和“Agent 行为变好了”不再混为一谈

Skill 优化领域还有一个常见误区：修改后的文档在静态比较中看起来更清晰，就被视为 Agent 能力已经提升。

但文本质量和行为质量并不是一回事。

一条规则写得更详细，可能让 Agent 更容易理解，也可能增加上下文负担；一套流程写得更完整，可能减少遗漏，也可能让 Agent在简单任务上过度调用工具；一句更强的限制，可能降低某类错误，却同时损害正常任务的完成率。

AET 因此明确承认：静态检查不能被包装成 Agent 行为证据。要声称 Skill 真实改善了 Agent 行为，需要显式启用真实 Host Adapter，让基线 Skill 和候选 Skill 在相互独立的 fixture 副本中完成配对回放，并记录结构化事件、前后快照、得分和哈希。Host 启动、认证或模型失败会被归类为基础设施错误，而不是 Agent 能力失败；样本量不足则保持 INCONCLUSIVE，不会被勉强判为通过。

这也是 AET 相比纯文档优化器更客观的一点。

它并没有声称自己已经解决了所有 Agent 训练问题，也没有把一个小型 fixture 的成功夸大为广泛泛化能力。仓库明确说明，内置真实 Host fixture 只是 proof-handoff 的烟雾测试。要做采纳级判断，团队仍然需要建立与自身任务分布匹配、彼此分离并持续轮换的核心集、验证集和留出集。

这会让系统显得不那么“神奇”，但也正因为如此，它更接近一个可以认真使用的工程工具。

AET 的自演进，并不是无人值守地修改生产规则

看到“自演进”三个字，很容易想象一个 Agent 在夜间自动分析日志、改写 Skill、提交代码并发布新版本。

AET 刻意没有这么做。

它可以在本地通过计划任务执行受限的 sleep 流程，采集证据、挖掘模式、生成有限数量的候选并运行回放，但默认不会上传原始记录，不会自动提交，不会推送，也不会采纳候选。

即使候选通过 Gate，也只是被 Stage 到一个供人检查的位置。真正的 Adopt 是另外一个明确动作，需要再次确认目标资产仍然匹配原始哈希，并写入本地 Decision Ledger。

这实际上把“自动化”和“自治”做了区分。

AET 尽可能自动化证据整理、模式发现、候选生成和重复评测，但不把生产规则的最终控制权交给候选自身。尤其是审计规则，即使确定性 fixture 全部通过，也必须先通过真实项目 Shadow 验证。

这种设计可能不如“全自动自我进化”听起来激进，却更适合真实团队。因为 Skill、审计规则和 Review Policy 并不只是模型参数，它们代表项目的治理边界。一条规则被自动加入，可能导致正常开发被阻断；一条审计规则被错误采纳，可能在大量项目中制造误报；一个 Validator 被放宽，可能让不合格的交付被错误接受。

在这些场景里，人类确认不是系统不够先进的表现，而是治理的一部分。

对普通开发者来说，它到底能解决什么

AET 最直接的使用场景，是 Agent 完成开发任务后的可信交付。

例如，你允许 Agent 修改 src/payment 和对应测试目录，并要求它执行单元测试、生成 JUnit 报告。AET 可以先记录人工批准的修改边界，再审查实际 Diff 是否越界；随后通过 Trace 明确执行测试命令，并确认报告是本次执行新生成或发生变化的产物；最后把 Audit、Review 和 Trace 结果打包成可携带的 Evidence Pack。

你得到的不再只是一段“我已完成”的 Agent 总结，而是一份可以交给同事复核的本地证据收据。

第二类场景，是反复出现的 Agent 行为问题。

假设 Agent 经常忘记在修改数据库 Schema 后同步迁移文档。你可以积累这些失败的结构化证据，确认它们不是偶发情况，再将问题路由到 Skill 候选。候选只允许修改 Skill 中标记过的可编辑区域，随后分别在核心任务、验证任务和留出任务上比较原始版本与候选版本。如果静态验证不足，还可以显式使用真实编码 Agent 执行配对任务，观察行为是否真正改善。

第三类场景，是审计能力的改进。

如果现有规则反复漏掉某种危险配置，可以记录具体的假阴性、原因代码和最小 fixture。候选 Audit Rule 必须在多个独立分区中通过误报、漏报、确定性和性能验证，再以 Shadow 模式进入真实仓库积累证据。它不会因为一次测试成功就立刻替换正式规则。

第四类场景，是项目治理逐渐变严格。

有些项目初期只要求基本测试，进入稳定期后，希望核心目录必须提供覆盖率报告，敏感路径的改动必须执行特定验证，安全发现需要更高的优先级。AET 可以让 Audit Profile、Review Policy、Trace Validator 和 Triage Policy 分别沿着单调收紧的方向演进，而不是把所有要求都塞进一份越来越庞大的 AGENTS.md。

第五类场景，是跨项目积累经验。

AET 可以将经过处理的 Evidence Only 经验包汇总到本地 Experience Store，再用于不同项目之间的模式挖掘。默认共享的是结构化偏差和哈希，而不是完整聊天记录、Shell 输出、环境变量和密钥。

对于维护多个仓库的个人开发者或团队来说，这意味着经验不必永远困在单个项目里，但也不需要先把全部 Agent 对话上传到某个托管观测平台。

如果你需要…	先使用	仅在需要时再增加
检查 Agent 本地指引是否可用	aet audit	需要发现/已读资产的哈希记录时使用 context。
交付 Agent 生成的改动	audit + review + trace	需要可移植交接时使用 evidence pack；多生命周期步骤时使用 run。
解释仓库为何形成当前结构	aet evolve plan	审查收集计划后再执行 collect/build/report。
改进反复出现的 Agent 行为	learn harvest + mine --target-type skill	propose/replay/gate/stage；只有显式配置时才使用真实宿主 Runner。
改进 Audit 漏报或误报	aet audit feedback record	按 audit-rule 挖掘，运行四分区 Fixture，再积累 Candidate 绑定的 Shadow。
收紧 Audit、Review、Trace、Triage Policy	learn target list	提供受限 JSON Patch，运行目标专属 Suite，Stage 后再显式 Adopt。

它相比其他工具的优势，不在于取代谁，而在于连接了原本分散的环节

AET 不应该被描述成 Cursor、Codex、Claude Code、CI、SkillOpt、Yao Meta Skill、OPA 或 Agent Observability 的替代品。它们解决的问题并不相同。

编码 Agent 负责执行任务，CI 和扫描器负责完成特定检查，Skill 工程工具负责创建和管理 Skill 产品，Skill 优化器擅长基于任务回放优化 Skill 文档，策略引擎适合执行预先定义的广泛政策，观测平台则擅长保存和查询大规模会话轨迹。

AET 的位置更像是这些工具之间的连接层。

它把 Agent 执行、人工意图、Git Diff、测试命令、产物、审计发现、项目决策和治理资产，通过一套本地证据模型串联起来；再让真实失败有机会进入多目标、受约束、独立评估的改进流程。

因此，它的核心优势可以概括为几句话：

它不是只让 Skill 可修改，而是让影响 Agent 工程行为的多类资产都具有受约束的训练接口。

它不是先相信 Agent 的总结，而是先确认命令、产物、哈希、工作区状态和未知项。

它不是让每一种资产各自建立一套“自进化脚本”，而是通过统一目标 Adapter 和生命周期管理整体演进，同时保留每一种资产独立的评估标准。

它不是用一个 LLM Judge 决定所有候选是否优秀，而是让评估器跟随目标：Skill 看 Agent 行为，Audit Rule 看确定性 fixture 和真实 Shadow，Policy 看专门的不变量测试。

它不是让候选既当运动员又当裁判，而是通过 Constitution、不可变区域、留出集、独立 Gate 和人工采纳限制候选权限。

它不是把所有聊天内容都当成训练数据，而是默认只保留含义明确、经过结构化的 Evidence Only 记录。

它也不是一个自动修改生产系统的守护进程。提议、评估、暂存和采纳被故意分开，让自动化停在治理边界之前。

工具类别	更适合解决什么	AET 增加什么，或刻意不做什么
Coding Agent Runtime（Codex、Claude Code、Copilot）	在仓库中规划与执行实际工作。	AET 不替代 Runtime；它记录 Runtime 的交付结论所需的本地证据。
CI、测试、Lint 与安全扫描	用各自的规则检查代码或部署。	AET 可 Trace 显式检查，并将其产物绑定到 intent、工作区 freshness 与 handoff；不替代检查器。
Skill 工程/治理系统（Yao Meta Skill）	创建、打包、编译、评估并治理可复用的跨平台 Skill 资产。	AET 聚焦交付证据，以及在用 Skill/Audit 资产的独立门禁改进。用 Yao 工程化 Skill 产品；用 AET 证明发生了什么、约束什么可以演进。
Skill 优化器（SkillOpt）	根据有分数的 rollout 与 held-out validation 训练 Skill 文档。	AET 提供本地工程证据语义：intent 边界、显式命令 proof、artifact、freshness 与人工 adopt；它不是通用 benchmark 优化器。
Transcript 分析 / Agent 可观测平台	搜索大规模历史会话、看仪表盘或管理 fleet telemetry。	AET 默认只保存结构化 Evidence Only 记录，不会摄取无限增长的 transcript 档案。
Policy Engine（如 OPA）	在多系统中执行广泛、预先定义的 Policy 语言。	AET 不替代通用 Policy Engine；只允许六类 AET 资产通过单调、白名单操作与证据 Gate 演进。
Evaluation Framework / LLM Judge	在广泛任务集上衡量模型或 Agent 能力。	AET 用命令、Artifact、Diff、Fixture 与显式状态验证工程声明；模型可以提案，但不能决定 Gate。

客观来看，AET 目前仍然有明显边界

如果把 AET 宣传成一个已经可以自动理解任何任务、训练任何规则并在所有 Agent 上稳定提升表现的通用自进化平台，那显然是不准确的。

目前它的可演进目标是注册过的六类 AET 资产，而不是任意项目文件。Audit Rule 的自动候选生成范围仍然较窄，其他多类 Policy 目标需要用户显式提供受约束的 JSON Patch。真实 Host 评估虽然已经提供 Codex 和 Claude Code Adapter，但真实效果仍然取决于任务集质量、样本量、模型波动和本地环境。内置 fixture 更适合展示机制和完成烟雾测试，不能替代每个团队自己的采纳级评测集。

它也不会替你设计测试，不会判断业务目标是否合理，不会代替人工 Code Review，更不会因为生成了一份 Evidence Pack，就自动证明软件已经安全上线。

但这些边界并不会削弱它的价值，反而说明它目前选择了一条较为务实的路线：先把能够验证的部分做窄、做清楚，再逐步扩大训练目标和评估覆盖，而不是先搭一个看似万能的自进化概念。

真正值得关注的，不是 Agent 会不会自己改 Prompt

AI 编程正在快速进入一个新阶段。

前一阶段，我们关心模型能不能写代码；后来，我们关心 Agent 能不能调用工具、修改仓库并完成长任务。接下来更难的问题会是：当 Agent 成为日常开发流程的一部分，我们如何知道它的交付可信，如何把真实失败转化为能力改进，又如何保证改进过程本身不会破坏原有治理边界？

只会执行任务的 Agent，更像一名速度很快但经验无法积累的临时成员。

只会保存 Memory 的 Agent，可能记住了更多内容，却未必知道哪些记忆经过验证。

只会优化 Skill 的系统，可以改善某类行为，却难以覆盖审计规则、Review Policy、验证器和优先级策略共同构成的完整工程环境。

AET 真正有辨识度的地方，在于它试图把这三个问题放进同一个系统中：工作需要留下证据，证据可以形成训练输入，训练能够作用于多类治理资产，而任何资产的变化都必须重新接受独立证明。

这不是一个让 Agent 获得无限自我修改权限的故事。

恰恰相反，它是在尝试回答：怎样给 Agent 建立可训练性，同时不放弃工程控制。

未来真正成熟的 Agent 系统，可能不会因为一次回答写得漂亮而被认为可靠，也不会因为自动修改了一份 Skill 就被认为完成了进化。它需要知道什么已经被证明，什么仍然未知；需要判断失败应该反馈给哪一种资产；需要在真实任务中比较改进前后的行为；还需要确保候选无法修改自己的考试规则。

从这个角度看，Agent Engineering Toolkit 不是又一个帮 Agent 写更多代码的工具。

它更像是在为 Agent 建立一套工程世界里的学习制度：工作有记录，失败有归因，改进有边界，评估有独立性，采纳有责任人。

Agent 并不会因为拥有这套系统就突然变得完美。

但至少，它犯过的错误不必永远只留在一次对话里。