让 Agent 的工作经得起验证

我最需要改变的是交任务的方法。过去我容易把“帮我做个功能”直接交给 AI，现在应该先交付一份范围明确、可以验收的任务说明，再让它执行。

可观测性也应该从自己的小项目开始：至少能回答它做到了哪一步、改了哪些文件、什么验证失败、为什么重试。只看最终回答，无法判断交付过程是否可靠。

课件展示的效率提升属于特定团队与任务条件下的实践报告。我不能把它直接当作自己的效率预期；应该记录自己项目中耗时、返工和缺陷的变化。

即使 Agent 说完成了，我能拿出哪些独立的交付证据？

我不应该把“多个 Agent”理解成让几个聊天窗口讨论。协同真正有价值的地方，是让不同角色面对不同信息和目标，再由同一个可执行环境评价结果。

我在算法和课程项目中学过目标函数与约束，这些知识可以直接迁移到 Agent 工程。先写出什么绝不能违反，再讨论优化；提示词里的承诺不能代替程序校验。

排错时我容易先盯住报错最多的服务。这场报告提醒我先建立调用链和时间线，区分故障传播与真正起点；历史案例是排查线索，仍需当前数据验证。

Agent 给出的部署方案，是否通过了每一项硬约束？

我以前可能把一次又一次追问当作迭代，但如果没有失败测试、预算和退出条件，迭代很容易变成无止境试错。我应该设计每一轮怎样判断进步。

对自己的学习项目，最有价值的做法是先把一个真实 bug 稳定复现，再让 Agent 修复，最后把这个用例保留下来。这样留下的是项目能力，而不仅是一段对话。

我可以从标题思考产品工作流如何 Agent 化，但不能据这一张照片推断金数据的产品功能、客户效果或公司内部完整架构。下面的行动建议是我的延伸方案。

下一次同类问题出现时，流程能否自动发现它？

我感受到的是软件测试需要环境建模能力。模型能生成源码，并不意味着理解了硬件行为；编译成功、probe 成功、深层路径覆盖是不同层次的证据。

如果将来做系统软件方向，我需要补齐 C、Linux 内核、设备协议与调试基础。LLM 可以帮助读代码和生成模型，但我仍要解释状态变化、内存交互与异常条件。

虚拟设备通过测试只能说明当前模型和输入下没有观察到问题，不能直接推导真实设备上的正确性。对模型真实性的评估也需要独立检查。

我验证的是模型能编译，还是驱动确实走到了目标路径？

这场最直接改变了我对 AGENTS.md 的期待：它可以表达约定，却不能单独保证约定生效。重要约束应当尽量成为每次运行的测试、静态分析或 CI 检查。

我也不能因为审查来自“另一个 Agent”就放松判断。几个角色使用同一个模型时仍可能重复犯错；必须让它们看代码、指出触发条件，并保留人工反证。

确定性脚本也可能误报或规则过时。正则检测比理解所有语义更稳定，但并非天然正确；我需要为检查器本身准备违规和合法两类样例，定期用历史缺陷回放校准。

这条审查结论能否被独立复现，或被明确反证？