很多团队一说要做业务 Agent，第一反应是搭一个自己的 Agent Framework：规划器、执行循环、工具调度、记忆、权限、人机交互，最好再做成平台。这个方向听起来完整，真正落地时却很容易把团队拖进基础设施泥潭。

我更倾向于反过来做：先把 Codex、Claude Code 这类通用 Agent 基座当成现成基座，让它们承担推理、代码理解、工具调用和多轮执行。业务团队的精力不要花在重写这些能力上，而是补它们缺的那部分：​业务知识、内部工具、流程规则、权限边界、评测集和线上观测​。

这样做不是偷懒。业务 Agent 的难点通常不在“模型会不会思考”，而在它能不能拿到正确上下文、调用正确系统、按团队规则停下来，并且在失败后留下可复盘的证据。把这些工程层做好，比从零造一个通用 Agent 更接近真实收益。

先跑裸基座：别急着写框架

建设前最该做的事，是拿真实任务让通用 Agent 裸跑一遍。这里的“裸跑”不是 demo，而是 ​10 到 30 个真实 case​：工单、告警、代码修改、发布检查、配置排查，都可以。团队先看清楚它原生能做到哪里，再决定补什么。

如果​裸基座已经能解决 60% 的任务​，团队应该围绕那 40% 的短板做增强。如果裸基座在关键任务上完全失效，也要先定位原因：是缺业务背景、缺工具、缺流程约束，还是安全边界根本不允许通用 Agent 接入。原因不同，方案差很多。

下面这条决策链可以作为立项前的第一道门。

图：从裸跑 baseline 到专项增强的立项判断链路

只有少数场景值得自研专项 Agent：强私有化环境、极端时延或成本约束、通用 Agent 无法接入的封闭运行时、必须深度嵌进业务系统的强流程任务，或者合规上不允许把任务交给现有基座。除此之外，先复用通常更快。

能力边界：通用基座做“智能”，团队做“落地”

业务 Agent 失败，很多时候不是模型笨，而是边界混乱。​通用 Agent 已经会读代码、拆任务、调用工具、根据观察调整路线​。团队要补的是它不可能天然知道的东西。

这张表背后的取舍很简单：不要让团队去维护一个“比 Codex 更懂代码、比 Claude Code 更会工具调用”的大系统。更有价值的是让通用 Agent 更懂当前团队，能看到内部系统，并且知道什么时候必须停下来。

图：通用 Agent 基座之外，业务团队真正需要补齐的是知识、工具、流程、安全与评测。

适合做 Agent 的任务长什么样

并不是所有需求都该做成 Agent。好的候选场景通常有几个特征：​高频、重复、边界清楚、工具可接入、结果可验证、风险可控制​。反过来，如果用户只说“帮我自动处理一切”，输入输出都说不清，Agent 项目大概率会变成无底洞。

我会优先选 Oncall 排障、发布前检查、代码迁移、灰度回归、数据修复辅助这类场景。它们有明确入口，也有证据来源。Agent 不需要凭空发挥，只要把散落在日志、代码、配置、工单和历史案例里的信息串起来。

增强层架构：把业务能力接到通用基座旁边

推荐架构不是“再造一个 Agent”，而是在通用 Agent 外面包一层业务增强。入口、知识、工具、流程、安全、评测各司其职。通用基座仍然处在执行中心，​增强层负责把真实业务世界接进来​。

图：业务入口、增强层与通用 Agent 基座的协作关系

各层的建设重点可以收敛成一张表。

第一版不必做完整平台。选一个真实场景，接入最小知识集和最小工具集，跑通闭环，再决定要不要服务化。

MVP 闭环：少做平台，多做可验证协议