工程实践中为什么有时"手搓"Agent 而不直接用现成框架？

这不是「框架 vs 手搓」的非黑即白，而是根据阶段和要求做的工程权衡。

框架的价值

LangChain、LangGraph、CrewAI 这类框架把 prompt 模板、工具调用协议、记忆管理、多步编排都封装好了，能在几小时内搭出一个能跑的 Agent。对于做 demo、验证可行性、或需求标准化的场景，它们极大降低了起步成本，没有必要重复造轮子。

框架的代价

• 过度抽象导致黑盒：实际发给模型的 prompt 被层层包装，出问题时难以定位是哪一层注入了什么，调试链路长。
• 依赖与版本不稳定：这类库迭代快、破坏性更新多，升级一次可能牵连一连串行为变化，生产环境维护成本高。
• prompt 难精细控制：很多关键 prompt 藏在框架默认模板里，想逐字调优、做 A/B、或适配特定模型的最佳实践时很别扭。
• 性能与成本不透明：框架可能在背后多发几次调用或塞入冗余上下文，token 成本和延迟不好掌控。
• 定制困难：一旦需求超出框架预设的编排范式（特殊的控制流、自定义重试与降级），往往要和框架「对着干」。

手搓的优势

直接用模型 SDK 自己写循环、自己拼 prompt、自己管工具调用，意味着：prompt 与控制流完全可控、每一步都看得见因而易调试和可观测、依赖少所以更稳定、代码按需裁剪因而更轻量。代价是起步要写更多样板代码，且要自己实现记忆、重试等通用能力。

判断标准

倾向框架：早期原型、需求通用且标准、团队对 LLM 工程经验有限、要快速验证。
倾向手搓或薄封装：核心业务系统、对 prompt 质量/成本/延迟有严格要求、需要深度定制控制流、需要强可观测与可控的故障处理。常见折中是只借用框架里少数稳定的工具组件，编排和 prompt 自己掌控，即「薄封装」。