这篇文章不只讨论“为什么不用造”。我把现在的做法收敛成三样可以直接拿走的东西一套默认架构、一张七问清单以及一套决定是否升级到自定义 Loop 的验收方法。最近我一直在想一个问题Claude Code、Codex 这类通用 Agent 都已经这么强了我们还有必要从 0 到 1自己造一个 Agent 吗这个问题不是凭空来的。我们内部也在做研发 Agent强烈安利很有必要按业务域部署在云端主要用于研发答疑、问题排查和需求开发。我们没有从 LangChain、LangGraph 开始写 Planner 和 Tool Router而是把 Claude Code 放进云端沙箱按业务域配置 Agent。它负责规划、编码和工具调用我们负责企业系统接入、Skills、MCP、权限、会话和可观测性。做了一段时间我的判断越来越明确企业当然要做 Agent但第一版不该从重写 Agent Loop 开始。所以这篇文章不只讨论“为什么不用造”。我把现在的做法收敛成三样可以直接拿走的东西一套默认架构、一张七问清单以及一套决定是否升级到自定义 Loop 的验收方法。1. 第一版先搭什么我现在有个明确答案如果今天有人跟我说“我们这个业务要做一个 Agent”我不会先问用 LangGraph 还是自己写状态机。我会先把通用 Agent 跑起来再补企业真正缺的部分。我们现在的研发 Agent大体就是下面这套结构以 Claude Code 为通用 Runtime在云端沙箱中按业务域配置研发 Agent企业能力横向共享图里最重要的不是订单、支付、客服这几个名字而是职责被拆开了。Claude Code 负责推理、规划、编码和工具调用。企业共享层提供 Skills、MCP、Hooks、权限、会话和可观测性。业务域 Agent 只装配自己能访问的 Repo、工具和规则到了具体任务再用独立的 Worktree 和 Session 隔离代码现场与上下文。这套第一版里我不会先做自定义 Planner、Router、Critic也不会因为要接一个内部系统就顺手造一套 Runtime。先复用通用 Agent 的 Loop把企业能力放到正确的位置。2. 一个需求进来我先问这七个问题架构有了接下来是怎么用。现在我拿到一个 Agent 需求会按下面的顺序往下问企业 Agent 建设七问先补知识、系统、边界、隔离、约束、流程和环境再评估自定义 Loop这个顺序是故意的。前面的办法改动小也更容易复用越往后成本和维护责任越重。只有七项都补过问题仍然落在运行时调度本身我才会讨论自定义 Loop。任务复杂也先这样拆。比如 Deep Research 要求“每个结论有多个来源、必须找反方证据”这是研究规范适合放进 Skill“取数 → 脱敏 → 审批 → 写入工单”是固定步骤交给 Workflow至于下一步搜什么、冲突出现后查哪条线索仍然让通用 Agent 判断。复杂不是一个架构层。先拆清楚缺的是知识、确定性流程还是自主决策。3. 用 SRE Agent 把这套方法跑一遍拿一个公司内部的 SRE Agent 来说它确实很“特殊”有自己的监控、日志、CMDB、发布系统还有一整套排障和生产操作规范。但按七问拆完落点其实很清楚排障 SOP 和历史经验做成 Skill。日志、监控、CMDB、发布能力接成 MCP 或内部 Tool。应用范围、可用工具和数据边界收进 SRE 业务域 Agent账号授权仍由企业权限系统执行。修改生产配置前的风险检查和人工审批放进 Hook / Policy。修改后的监控验证、失败重试和工单回写用 Workflow 固定。命令执行放进 Sandbox每次故障使用独立 Session涉及代码修改时再分配 Worktree。这里真正需要通用 Agent 判断的是“下一步先查指标、日志还是最近变更”。其他能确定的东西都在 Loop 外变成工具、边界和门禁。高风险操作和结束校验都在 Agent Loop 外设置确定性门禁这样搭出来的 SRE Agent 业务很特殊但 Loop 并不特殊。它已经能访问内部系统、遵守生产规则、隔离执行环境也能在高风险操作前停下来等审批。这也是我现在更愿意采用的默认方案让通用 Agent 处理不确定的判断企业负责把确定的知识、能力和约束接牢。4. 什么时候我才会把 Loop 拿回来七问都走完以后如果通用 Agent 仍然不够我会继续看两个条件。第一个Loop 本身就是产品的核心算法。团队确实做出了一套专用的 Planner → Worker → Critic → Replan 策略而且它决定了最终效果不只是把通用 Agent 的调用换了个写法。第二个任务足够固定、调用量足够大通用 Agent 的 Token、时延或人工介入成本已经不可接受。通过裁剪上下文、减少模型轮次和固定部分路径专用 Loop 可能更划算。但“感觉更快”不算证据。我会用同一组真实任务做一次对比模型、工具和成功标准保持一致一边跑通用 Agent另一边跑专用 Loop再看成功率、平均 Token、P95 时延和人工介入率。用同一任务集对比通用 Agent 与专用 Loop按四项指标决定是否升级目标值要在测试前定好。只有收益稳定、可以重复并且足以覆盖专用 Loop 的开发和维护成本我才会升级。某几个样例跑得更快或者只是流程图画得更可控都不够。分界线不是“我们能不能写 Loop”而是“我们能不能证明拿回 Loop 有收益”。5. LangGraph 不是起点而是通过验收后的升级项所以我并不觉得 LangGraph 没用了。它的位置变了。我现在更认可的建设顺序是业务需求 → 先跑通 Claude Code / Codex → 用七问补齐企业能力 → 在固定任务集上建立基线 → 仍然不够并且专用方案能证明收益 → 再用 LangGraph 或自研 Runtime 控制 Loop回头看我们自己的研发 Agent真正需要长期建设的不是几十套 Planner 和 Tool Router而是能被不同业务域复用的 Skills、Tools、Sandbox、权限、会话和可观测性。以后再有人说“这个业务需要做一个 Agent”我会先把七个问题走一遍再问一句通用 Agent 到底还差什么如果答案只是知识、工具、规则、流程或环境就把那一层补上。只有问题最终落在 Loop 本身而且数据证明值得才从 0 到 1 自己造。最后我们整理出这套 AI 大模型 突围资料包✅ 从零到一的 AI 学习路径图✅ 大模型调优实战手册附医疗/金融等大厂真实案例✅ 百度/阿里专家闭门录播课✅ 大模型当下最新行业报告✅ 真实大厂面试真题✅ 2025 最新岗位需求图谱所有资料 ⚡️ 朋友们如果有需要 《AI大模型入门进阶学习资源包》下方扫码获取~资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。需要这份AI大模型资料清单的话在评论区回复「清单」即可我会根据大家的问题继续补充对应的实战内容。