加载失败
这次讨论围绕一篇汇总“Agentic Engineering Patterns”的指南展开，作者意在收集用 LLM-based agents 编写、测试和部署软件的实践。评论来自混合背景的工程师，讨论集中在三大问题：如何用可执行的 test harness 和 red/green TDD 约束非确定性输出、生成代码后谁负责 code review 及质量保障、以及模型进化如何改变当前的工程模式。讨论引用了若干工具与理念作示例——例如 Claude Code（用于代码生成的 agent 工具）、StrongDM 的 Dark Factory 原则（自动化/工厂化运维理念）、Playwright（浏览器自动化测试框架）和 WASM（WebAssembly，浏览器/边缘的字节码目标）——并强调可观测性、决策日志和部署时的硬件约束在落地时的重要性。
大量评论指出担心把已有的、平实的软件工程实践重新命名为“agentic”或其它花哨术语会催生一波咨询、培训和认证产业链。评论里把这种循环比作历史上的 COBOL 话语：语言承诺让非程序员能做开发，但实际上问题在于需求拆解本身仍然需要程序员的思维。有人描绘了标准流程：博客→演讲→书籍→顾问→认证，认为这一过程被压缩加速，会带来大量“热空气”和投机者。尽管有人承认模式可能有价值，但普遍呼吁警惕商业化话语侵蚀技术判断力与实务落地。
许多评论把测试视为将非确定性 LLM 输出约束为可发布代码的唯一可靠手段，强调要有可执行的 test harness、integration/E2E 测试和红绿（red/green）TDD 循环。评论里具体列出了常见的陷阱：LLM 会写出“自洽”或“应验式”测试（tautological tests）、在测试中硬编码期待值，或者为了让测试通过而改变实现（例如删除并发逻辑），因此要使用 mutation testing（变异测试）或先让测试失败再实现以验证测试的有效性。实践建议包括让 agent 先生成计划、把失败测试作为“成功信号”并把 lint/集成测试纳入流水线，还要警惕测试膨胀带来的 CI 成本与伪覆盖率。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
当 agent 能在几分钟内生成大量 PR 时，人工 Code Review 变成主导发布速度的瓶颈，评论中多次提到“把大量 agent 产出丢给别人 review”是一种反模式。有人建议把 agent 产出当作初级工程师的工作：拆成原子提交、强制测试覆盖、要求提交者为每一行代码负责并能为设计辩护，或在生成前审查 prompt/规格以减少废工。也有人提出用审核 agent 作为代理或在 PR 流程中植入强制检查（如 AGENTS.md、审查清单、必过的质量闸），但强调最终要有人类承担验证责任以避免“让别人做你的 QA”。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
多条评论提出一套实用做法：用 plan mode（计划模式）先产出并审阅实施计划、在会话间维护 decisions.md/constraints.md 之类的决策或“拒绝日志”、并把可观测性和可回放的 traces 放在架构前端。具体工具实践包括把不可见的约束写入 append-only 的结构化日志并用查询接口（如 MCP/ctlsurf）让 agent 查询，利用 showboat/rodney/StrongDM 的 Dark Factory 思路进行 demo 验证与视觉校验，以及在 web 场景用 Playwright 做检查点。核心主张是先把可理解、可复现和可溯源的监控/评估做扎实，再考虑多 agent 的复杂编排。
评论普遍认为 agent 最擅长有明确验证信号且高度模式化的任务：生成样板代码、CRUD、前端模板、强类型/良好测试的后端以及能用自动化测试明确判断优劣的优化问题。相反，复杂的领域逻辑、需要深度专业知识或与硬件/性能/并发紧耦合的任务仍常出错，常见问题包括 hallucination（幻觉）、错误的 API 调用、绝对布局等低级错误。实践经验还指出：在熟悉的代码库里人工手写常常更快；但在跨多个不熟悉代码库、或需要大量重复改动时，agent 能显著加速工作流。
有人提醒，多数复杂的 agent 编排最初是为了解决老模型的局限（小 context window、低吞吐），而新一代模型和更大的 context 可能会使很多设计成为过拟合的工程。举例来说，早期围绕 LangChain 的大量工程在 GPT‑3.5 出来后被简化或废弃，评论预测随着上下文、吞吐和成本改进，单个 agent 或更简单的流水线可能足以应对很多场景。与此同时也有人主张保留模型无关的模式（如测试驱动、可观测性），因为这些原则在模型更替中仍然有价值。
讨论扩展到组织与人力层面：一方面有公司报告用 agent 将生产力倍增（例如把三人工作浓缩为一人+工具），另一方面有人担忧长期后果——个体把理解/判断外包给 LLM，团队技能退化，若某人用 agent 超越整个部门会引发管理和人事问题。评论还牵涉到伦理与法律：训练数据来自大量开源/商业代码（版权问题）、以及“把常识包装成证书/卖课”的市场化倾向。多位评论者呼吁明确模式的适用范围并关注治理与责任分配，而不是盲目追求效率。
若把 agent 产出部署到生产或边缘设备，会遇到 x86 测试无法发现的 ARM/Jetson 特有问题，如 OOM、热限制或硬件相关 bug，评论指出这些问题会把“代码便宜”带来的好处抵消。实务建议包括把可观测性和评估（evals）放在首位、避免在没有可靠日志与追溯的情况下堆叠多 agent 架构，以及在不同平台上做真实的回归测试。总体结论是：生产约束仍然决定可信度，不能只看模型生成速度或短期产出量。
Agentic engineering / 代理式工程: 用可组合的 LLM-driven agents 执行软件工程任务的工作流集合，强调代理的规划、工具调用、测试循环与管道化协作。
red/green TDD: Red/Green TDD：先写会失败的测试（red），再实现代码使之通过（green），用于强制测试先行并验证测试实际捕捉到缺陷的开发模式。
test harness（测试夹具/验证流水线）: 可自动执行、可重放的测试与验证环境，用以把 agent 的试验变成可评估的闭环（例如 CI、集成/E2E 测试、Playwright 驱动的检查点）。
mutation testing（变异测试）: 通过向代码注入小改动（mutants）来检验测试套件是否能捕捉缺陷，从而发现 tautological 或无效的测试。
plan mode（计划模式）: 某些 agent 平台里的工作流：先让 agent 生成详细实施计划并由人或其它 agent 审阅，再执行生成/修改代码，降低盲目执行和幻觉风险。
constraint log / 约束日志: 一类 append-only 的决策或拒绝记录（例如 decisions.md / rejections.md），用于保存已尝试或被排除的方法，供 agents 查询以避免重复试错。