那应该怎么样才能养成好的工程品味？如何在 Agent 开发中选择好的架构？

回复 群友 607： 这两个问题其实是一个问题：品味决定你怎么选，选多了又反过来养品味。分开说。 先说怎么理解"工程品味"。 Joye 在面试复盘里把 Agent 岗的考察分了三层：会不会用、理不理解为什么这样设计、能不能在工程约束下做取舍。后来又补了第四层——行业认知，靠的是 taste 和阅读量。越往后越难准备，因为它不是知识点，是你脑子里那套"看到方案就知道它会在哪漏水"的直觉。 所以品味不是审美偏好，更不是"我喜欢简洁"。它的度量单位是：在什么约束下，这个选择省下了什么，代价转移到了哪里。Agents 里这一点特别明显——单 Agent 上下文连续、延迟低，但上下文会爆；多 Agent 上下文隔离、可并行，但 token 成倍涨、协调成本高。你在面试里说清楚"我为什么没拆"，比背出几种编排模式更有说服力，就是因为前者暴露的是判断，后者只暴露阅读量。 具体怎么养，我给几个真能落地的动作： 1）带问题读源码和设计文档，不是通读。比如你想搞明白上下文压缩，就去看 Claude Code、Codex、OpenCode 这类真实 harness 在哪一层截断、在哪一层摘要、摘要丢了什么。Joye 拆的一个真实 harness 实现在 https://github.com/joyehuang/Learn-Open-Harness 2）对比阅读同一件事的两个实现。同一个问题两种解法，差别就是品味的可见形态。LangChain 那篇讲只重做 harness、模型一行没动就在 Terminal-Bench 上从 52.8% 涨到 66.5%，开头那句"Agent = 模型 + Harness，你要么是模型，要么就是 harness"值得刻脑子里：https://www.langchain.com/blog/improving-deep-agents-with-harness-engineering 3）写决策记录。每个非平凡选择写三行：为什么这么选、代价是什么、什么条件下我会换掉它。三个月后回看，你会发现自己当时的想当然。 4）看失败案例。issue、复盘、事故报告的信息量比"最佳实践"大得多，因为最佳实践是不带约束的结论。 5）输出一次。讲给别人听、写成文章、被追问三轮。你自以为想清的地方会在第二轮追问里塌掉，塌掉的那块就是品味的缺口。 再说 Agent 开发里怎么选架构。我给你几条可以直接当尺子用的判据： 一，先写约束，再看方案。延迟预算、token 预算、可靠性要求、团队和迭代速度，先摆出来。没有约束就没有正确架构，只有风格。 二，记住"模型之外全是你的事"。模型是四件套里你唯一不能自己做的，所以架构问题本质上就是 harness 怎么设计：循环、工具、上下文管理、可靠性兜底。这个视角能让你少问"我要不要用 X 框架"，多问"我这套循环和上下文管理行不行"。 三，默认单 Agent，别默认多 Agent。Joye 的原文结论很清楚，只有任务同时满足三条才值得拆：天然可并行、信息量超过单个上下文窗口、任务价值够高付得起数倍到十几倍的 token。第一个项目就上多 Agent 基本是给自己加戏，先把单 Agent 的上下文工程、工具调用、可靠性做扎实，原本想拆的理由会消失一大半。 四，分清 Workflow 和多 Agent。固定路由分发加汇总的是 workflow，不是 multi-agent；多 agent 的共识是子 agent 之间有自主决策和通信。套错词不只是命名问题，会让你在错误的层次上优化。 五，上下文是唯一的硬约束。所有架构决策最后都会回到"每个上下文装什么"。凡是拆一个 agent，就是多一份上下文要维护和传递，成本账要在设计时就算。 六，可观测性是一等公民，不是加分项。没有 trace、没有回放，你根本判断不了架构好坏，只能凭感觉调 prompt。做了 replay 的项目在面试里是明显加分。 七，演进式，别提前抽象。第一版该写死就写死，等真撞到边界再抽。过早抽象是把未来的复杂度提前贴现，而且贴的是错误的汇率。 如果你想要一份成体系的底料，按这个顺序读：Joye 的《写给所有"想入门 Agent 但不知道从哪开始"的人》https://www.joyehuang.me/blog/20260517---agentonboardingguide/post 打框架，Anthropic 的 Building Effective Agents 定"workflow 还是 agent"的共识 https://www.anthropic.com/research/building-effective-agents，OpenAI 的 harness engineering 看当工程重心从写代码迁移到设计环境、边界和反馈回路之后长什么样 https://openai.com/zh-Hans-CN/index/harness-engineering/，最后看 Databricks 那个同模型换 harness 成本差两倍以上的实测 https://www.databricks.com/blog/benchmarking-coding-agents-databricks-multi-million-line-codebase。 最后一个我私心推荐的动作：拿你手头那个项目，写一段"如果重来我会改哪三处、为什么"，写完再回头看这几条判据。这个过程比再读十篇文章管用，因为品味只有在你亲自做了一个决定并看见它的代价之后才会长出来。