成熟 Agent、开发框架还是自建 Harness：三条建设路线怎么选

团队决定引入 Agent 时，常见的第一反应是挑模型或挑框架。项目还面临一个更早的选择：直接使用 Claude Code、Codex、OpenClaw 这类成熟 Agent，还是为自己的业务开发一个 Agent？如果决定开发，继续使用 LangGraph、AutoGen、Pydantic AI、CrewAI 等框架，还是把 Agent Loop、状态和执行层握在自己手里？

这三条路线都能做出“模型调用工具并连续行动”的系统。它们的差别主要在责任所有权。谁定义消息和事件，谁保存状态，谁解释超时，谁升级模型协议，谁处理越权动作，谁为一次失败提供完整轨迹。功能演示很难暴露这些差别，系统运行几个月后却会每天遇到。

本文要回答的问题是：团队应该依据什么证据，在成熟 Agent 产品、Agent 开发框架和自建 Harness 之间做选择？

事实边界来自各产品和框架的官方文档、公开仓库，以及本文给出的工程推演。没有公开的产品内部细节不会拿来比较。文章也不评一个框架“综合实力”有多强，因为版本、生态和模型支持会持续变化。这里比较的是更稳定的部分：每条路线替你承担哪些责任，又把哪些责任留给你。

先给结论

如果成熟产品已经覆盖任务边界，先用产品。Coding Agent 就是典型例子：仓库读取、文件编辑、命令执行、权限确认、Diff 和任务恢复都已经被产品组织起来，团队无需先造一套运行时。

业务需要自定义工具、状态和审批，但持久化、编排、人机协作等语义可以接受框架的抽象时，使用开发框架。框架的价值是让团队从业务节点开始，而不用先处理每一种流式事件和恢复路径。

只有在运行时语义本身属于核心需求时，才值得自建 Harness。典型信号包括严格的执行隔离、特殊的任务恢复、跨模型协议、内网部署、确定的事件模型，或者框架抽象已经持续阻碍关键路径。自建意味着同时接手兼容、安全、观测、评测和升级。

路线	适合的起点	团队主要负责	最容易低估的成本
成熟 Agent 产品	已有产品与任务高度匹配	配置、权限、接入、验收与使用规范	产品边界、数据边界和流程迁就
Agent 开发框架	需要自定义业务流程和工具	业务状态、节点、策略、部署与评测	框架语义、版本迁移和调试抽象
自建 Harness	必须拥有运行时和执行语义	从 Loop 到安全、恢复、观测的全部责任	长期维护、协议变化和失败长尾

这不是从低级到高级的三个台阶。一个团队完全可能在代码开发上使用 Codex，在客服流程上使用 LangGraph，在高风险内网执行上维护一套很小的自建 Harness。选择单位应该是具体任务和责任边界，不是整家公司统一押注一个技术名词。

一、先把三条路线说清楚

“使用产品”和“使用框架”经常混在一起，因为很多产品也提供 SDK，很多框架也提供托管部署。判断时不要看它有没有 API，而要看运行语义由谁定义。

成熟 Agent 产品：在既定工作方式里完成任务

成熟产品已经把模型、Harness、工具和交互界面组合成可直接工作的系统。Claude Code 围绕终端和代码仓库组织任务，Codex 用线程、工作区、审批和 Review 管理工程任务，OpenClaw 则面向多渠道接入、长期会话和自动化。它们覆盖的任务不同，共同点是用户在产品定义的生命周期里工作。

以 Coding Agent 为例，产品通常已经处理文件读取、Shell、补丁、上下文压缩、权限询问和结果展示。用户仍要写清需求、提供仓库规则并检查结果，但无需定义 tool_use 事件如何变成进程、进程超时后怎样回到模型、会话如何续接。具体机制可以参考 Claude Code 工作原理、Codex 开源仓库 和 OpenClaw 架构文档。

选产品先看任务适配度。模型支持只是其中一项；如果团队的流程必须围绕自己的业务对象、审批状态和审计记录运行，产品提供再多工具也可能只是外围执行器。

Agent 开发框架：复用运行原语，自己写业务系统

框架给开发者一组可组合原语。不同框架的重心不一样：LangGraph 把自己定义为面向长任务和有状态 Agent 的低层编排框架，重点包括持久化、Durable Execution、Human-in-the-loop 和确定步骤与模型步骤的混合；AutoGen 区分 AgentChat 和更低层的 Core，前者提供预设 Agent 与团队模式，后者使用事件驱动 Runtime 支持可扩展的多 Agent 系统；Pydantic AI 强调类型化依赖、工具和结构化输出，并继续提供持久化、图、评测与可观测能力；CrewAI 用 Crew 和 Flow 表达角色协作与业务流程。

框架不会替团队决定业务完成条件。它可以保存图状态，却不知道退款是否真正到账；可以提供人工中断，却不知道哪类订单必须由谁批准；可以重试节点，却不知道远端扣款超时后是否允许再次执行。框架把通用问题变成 API，业务语义仍由应用负责。

自建 Harness：连运行语义也由团队拥有

自建 Harness 通常仍会使用模型客户端、数据库、队列、沙箱和观测库，无需从头训练模型或重写所有 SDK。团队自己定义模型之外的执行闭环：消息怎样进入模型，工具怎样被校验和调度，状态怎样落盘，失败怎样分类，任务怎样恢复，完成怎样验收。

最小循环可以很短：

def run_agent(task, tools, store):
    state = store.load_or_create(task)

    while state.status == "running":
        response = model.generate(
            messages=build_context(state),
            tools=tools.schemas(),
        )
        state.record(response)

        if response.tool_calls:
            for call in response.tool_calls:
                result = tools.execute_checked(call, state.policy)
                state.record(result)
            store.save(state)
            continue

        state.status = verify(response, state.evidence)
        store.save(state)

    return state

这段代码还没有处理超时、结果未知、取消、并发工具、流式事件、压缩、审批和沙箱。自建的成本主要藏在这些分支里。Learn Claude Code 适合观察功能怎样逐章挂到循环上，Pi 则展示了一个小型 Agent Core 如何把消息、工具、事件与上层 Coding Agent 分开。它们都说明一件事：循环本身不难，稳定的外围契约才占据大部分工程量。

二、比较责任所有权

功能表会让三条路线看起来越来越相似。产品能接 MCP，框架能部署成服务，自建 Harness 也能复用开源工具。把比较单位换成责任以后，边界清楚得多。

图中的“共同承担”最容易被忽略。成熟产品提供权限界面，不代表团队可以跳过权限设计。团队仍要决定允许产品访问哪些仓库、密钥和服务，也要审查生成的修改。框架提供 Checkpoint，不代表业务恢复已经成立。应用必须知道一个节点重跑会不会重复发信、重复下单或覆盖用户刚刚修改的数据。

界面、Loop 和执行环境是三份责任

一个 Agent 产品通常同时交付界面、Loop 和执行环境。开发框架主要覆盖 Loop、状态或编排，界面与执行环境要由应用补齐。自建 Harness 则要明确三者之间的协议。

这一区分会直接改变项目估算。一个用框架写出的 Demo 可能只有两百行，因为本地 Python 进程同时承担了服务、执行器和状态存储。上线后，团队才发现还缺身份、租户隔离、任务取消、发布策略和数据保留。Demo 行数不能代表生产责任已经被框架承担。

所有权也决定故障由谁解释

产品更新后行为改变，团队首先检查产品设置、发行说明和集成边界。框架升级后状态无法恢复，团队要判断是应用 Schema、序列化版本还是框架迁移问题。自建 Harness 出现同样故障，事件定义、存储兼容和恢复代码都归自己。

因此选型时应该建立一张责任清单，而不是只列功能：

责任项                 谁定义语义      谁运行      谁监控      谁处理升级
任务状态               ?              ?           ?           ?
工具执行与幂等         ?              ?           ?           ?
权限与审批             ?              ?           ?           ?
上下文压缩             ?              ?           ?           ?
失败恢复               ?              ?           ?           ?
轨迹与评测             ?              ?           ?           ?

任何一个问号没有负责人，都会在上线后变成事故中的争论。

三、什么时候优先使用成熟 Agent 产品

成熟产品适合已经被反复解决、工作界面相对稳定的任务。Coding Agent 的输入是代码仓库、需求和环境反馈，输出可以用 Diff、构建和测试验证；这类任务有天然工具和客观反馈，因此产品能够提供很完整的闭环。Anthropic 对 Agent 模式的总结也把 Coding Agent 作为适合开放循环的例子，原因包括自动化测试和清晰的环境反馈。

四个判断条件

第一，任务对象能够进入产品的工作空间。代码在受支持的仓库里，文档在产品能访问的知识源里，渠道消息能通过已有 Connector 进入。大量信息需要手工复制时，产品只覆盖了表面交互。

第二，产品的动作模型与业务风险相符。读文件、改代码和运行测试可以在隔离工作区完成；付款、删除生产数据或批量发信则需要更严格的身份、审批与幂等。产品如果不能表达这些边界，就不该直接拿到动作权限。

第三，完成条件能在产品里验证。Coding Agent 可以展示 Diff 和测试结果，研究 Agent 可以给来源，工单 Agent 可以更新状态并返回工单 ID。只能生成一段看起来合理的文字，却无法核对外部结果，闭环仍在用户手里。

第四，数据、部署和审计要求允许使用该产品。这里要看实际合同、部署形态和组织政策，不能从“支持企业版”推导出一定满足本公司的要求。

产品路线仍有集成工作

团队通常还要建设三类外围能力：仓库或业务规则、工具和数据接入、验收与审计。Claude Code 的 Hooks、Skills 和 MCP，Codex 的 AGENTS.md、环境与任务机制，OpenClaw 的渠道、Sandbox 和 Automation，都让产品适应具体环境。这些配置属于集成层，不代表团队已经接手产品内部 Loop。

扩展点够用时，产品加一层薄集成往往比另起框架更便宜。比如内部代码规范可以写进仓库规则，部署只暴露一个带审批的工具，验收脚本由 CI 运行。只要产品仍然负责会话、工具协议和交互，团队拥有的只是业务边界。

何时应该离开产品路线

不要因为界面不顺手就立刻自研。先找结构性限制：业务状态无法映射到产品任务；必须嵌入自己的用户界面；同一任务需要跨天等待外部事件；权限模型表达不了组织规则；执行必须在特定内网或硬件中完成；完整事件和状态无法导出，导致审计或恢复不可行。

这些限制需要用真实任务记录。写清哪一步被阻塞、采用了什么变通、变通带来多少人工成本或风险。没有这份证据，团队很容易为了“更自由”重做产品已经解决好的部分。

四、什么时候使用 Agent 开发框架

框架适合“业务需要自定义，运行原语可以复用”的项目。它通常出现在产品路线和自建 Harness 之间，但并非临时过渡。许多系统长期使用框架，因为框架提供的状态、编排和观测正好匹配需求。

从缺失能力反推框架类型

如果任务的难点是长时间运行、暂停恢复和确定步骤与模型步骤混合，图或 Durable Execution 类框架更合适。LangGraph 官方文档明确把自己定位为低层编排 Runtime，并把持久化、Human-in-the-loop 和 Memory 作为核心能力。选择它意味着接受 State、Node、Edge 和 Checkpoint 这套表达。

如果难点是多个角色或 Agent 之间的消息协作，可以看 AutoGen AgentChat、Core 或 CrewAI。AutoGen 的 AgentChat 提供预设 Agent 和 Team，Core 则使用消息与 Runtime 表达更底层的多 Agent 系统。抽象层不同，接手的责任也不同。一个只需要单 Agent 加两个工具的业务，没有必要先引入团队通信模型。

如果 Python 业务更在意类型化依赖、结构化输出和测试，Pydantic AI 的 Agent 把 Instructions、Tools、Output Type、Dependencies 和 Model 放在同一个类型体系里。类型能减少接口错误，但业务结果仍要外部验证。结构化输出符合 Schema，只能说明形状正确。

选择框架时要做一次“去框架”测试

用一页纸写出系统在框架之外的语义：

输入：任务、用户身份、资源范围
状态：目标、阶段、外部动作、证据、预算
动作：工具名、参数、副作用、幂等键
中断：等待用户、等待外部事件、权限拒绝
结束：成功、失败、取消、结果未知

如果离开框架名称就说不清系统，说明团队正在把业务设计外包给 API。框架升级、替换或出现边界问题时，这种系统很难迁移。相反，业务状态和动作契约清楚后，框架只是承载它们的一种 Runtime。

框架隐藏的四类成本

一是控制流成本。框架预设的重试、消息传递和状态合并是否符合业务？自动重试对只读检索很方便，对产生副作用的工具可能造成重复执行。

二是调试成本。框架事件、模型消息、业务状态和外部日志能否通过同一个 Trace 对齐？如果一次失败要在四套对象之间手工拼接，抽象节省的代码会转成排障时间。

三是迁移成本。状态快照和消息对象是否带有框架版本，升级后能否继续恢复旧任务？长任务系统必须测试跨版本恢复，不能只测试新任务能不能启动。

四是部署成本。框架提供 Checkpoint API，不代表它提供满足生产要求的数据库、队列、隔离和容量治理。要逐项核对开源库、托管平台和团队自建部分。

框架选型不要从 Hello World 开始

准备三个带故障的 Spike，比照着 Quickstart 跑通更有信息量：

1. 工具已经成功，但客户端在收到结果前超时，系统能否查询状态而不是盲目重试；
2. 任务等待人工审批一晚，第二天升级服务后能否从原状态恢复；
3. Context 接近上限，压缩后是否保留目标、权限和未完成动作。

候选框架都能完成正常路径，差别往往在这些不顺利的路径里。

五、什么时候自建 Harness

只有需要拥有运行语义时，自建才合理。模型 API 的工具调用已经让最小循环很容易实现，难点在于团队是否愿意长期承担外围责任。

值得自建的信号

执行环境是产品核心。比如 Agent 要在自研沙箱、边缘设备、专用计算集群或强隔离内网里运行，进程、文件、网络和凭证的生命周期都有特殊规则。通用框架只能包一层适配器时，运行时本身已经成为产品的一部分。

状态与恢复具有业务含义。一次任务可能跨越几天，等待多个外部事件，并要求精确区分已执行、未执行和结果未知。通用 Checkpoint 能保存对象，无法替团队定义补偿、幂等和版本迁移。

模型与工具协议需要统一治理。团队同时支持多个模型提供商、私有模型和不同工具协议，希望对流式事件、Token 预算、工具并发与错误语义提供稳定接口。这类控制平面适合由团队拥有。

安全边界高度特殊。权限要结合组织身份、数据等级、租户、时间窗口和动作风险计算，且所有决策必须进入审计。把规则塞进 Prompt 或框架回调通常不够，需要独立策略层和执行层。

自建前先写维护清单

如果清单里只有 Agent Loop、Prompt 和工具注册，估算还停留在 Demo。至少要回答：

• 模型协议升级由谁跟进，旧会话如何兼容；
• 流式事件是否有稳定 Schema，能否重放；
• 工具超时怎样区分失败和结果未知；
• 状态是否支持取消、恢复、迁移和并发控制；
• 权限、沙箱与业务审批如何分层；
• Context 怎样裁剪，压缩前后保存哪些不变量；
• Trace 如何关联模型、工具、进程和外部回执；
• 固定评测集、成本预算和灰度回滚由谁维护。

每一项都需要明确 Owner。没有 Owner 的自研 Harness 迟早会变成几位早期开发者才敢修改的基础设施。

自建也要克制抽象

先支持一个模型协议、一个任务类型和少量工具。用真实失败推动抽象：第二个模型暴露差异后再定义统一事件，第二种执行环境出现后再抽象 Sandbox，恢复需求确认后再设计 Journal。提前设计通用 Agent 平台，很容易得到大量没有调用者的接口。

Anthropic 的工程总结建议优先使用简单、可组合的模式，也提醒框架可能遮蔽 Prompt 和响应。这个建议同样适用于自建系统：拥有底层代码并不会自动带来透明度。没有结构化事件和评测，自研 Loop 也可能比框架更难调试。

六、用同一个代码修复任务走三条路线

假设团队有一个真实任务：修复支付服务中的偶发重复通知。验收要求是新增回归测试，现有测试通过，只允许修改支付模块，最终提交 Pull Request，不允许部署。仓库在公司 Git 平台，问题单和日志在内部系统。

路线 A：让成熟 Coding Agent 完成仓库内闭环

把问题描述、允许修改的目录、测试命令和完成条件交给 Coding Agent。通过 MCP 或受限脚本提供只读的问题单与日志查询。Agent 在隔离工作区读取代码、修改文件、运行测试并生成 Diff。人检查修改后决定是否推送 Pull Request。

这条路线最短，因为产品已经拥有代码搜索、文件编辑、Shell、会话和 Review。团队只需要处理内部数据接入和权限。若问题单内容、日志证据和代码都能进入产品允许的环境，任务很快可以验证。

阻塞点也很清楚。如果产品不能进入内网，或者组织要求每次日志查询都使用员工身份和细粒度审计，就不能靠复制日志长期绕过。产品路线的适配边界已经出现。

路线 B：用框架组织内部排障流程

团队可以把流程写成有状态图：读取问题单，检索日志，定位代码，生成候选补丁，运行测试，等待人工 Review，创建 Pull Request。每个节点使用内部身份系统，状态保存任务 ID、证据、修改文件和测试结果。人工 Review 是显式中断点。

框架提供图执行、Checkpoint 和恢复，团队实现业务节点与工具。服务重启后可以从 Review 前继续，不必把整段历史重新交给模型。代价是团队要建设代码执行环境、Diff 展示、身份和发布服务。

如果任务之后扩展到多种仓库和审批流程，框架路线的投入容易复用。若只有偶尔几个代码问题，这套系统可能比直接使用产品贵得多。

路线 C：自建受控的代码执行 Harness

假设支付仓库只能在专用内网执行，工具调用必须进入公司的策略引擎，所有模型和工具事件要使用统一协议记录，长任务要跨版本恢复。团队便有理由拥有 Loop、事件、状态机、Sandbox Adapter 和 Policy Adapter。

模型发出 query_logs 时，Harness 根据用户身份和事故编号生成审计请求；发出 run_tests 时，在短生命周期 Sandbox 中执行；发出 create_pull_request 时，程序检查测试证据、文件范围和审批状态。任务结束条件由验收器判断，模型的最终文字不能直接把状态改成 COMPLETED。

这条路线对约束表达最强，建设面也最大。团队还要维护 IDE 或网页入口、代码检索、任务队列、执行镜像和版本兼容。只有这些控制需求长期存在，自建才比框架适配更合理。

三条路线怎样验收同一个任务

证据	成熟产品	开发框架	自建 Harness
修改范围	产品 Diff，加人工检查	节点输出与文件白名单	执行层强制目录策略
测试结果	产品终端记录	测试节点结构化保存	Test Event 与产物仓库
内部日志访问	Connector 或受限 MCP	自建工具节点	策略层与执行层统一审计
人工 Review	产品 Review 界面	Human-in-the-loop 节点	自定义状态机与审批协议
恢复	产品会话能力	框架 Checkpoint	自有 Journal 与版本迁移

差别不在模型会不会写修复，而在证据和责任落在哪里。

七、六个维度做选型

决策会受到组织政策和现有技术栈影响，但六个维度几乎每次都值得检查。

任务适配度

先看 20 个真实任务，不看产品演示。记录输入在哪里、要调用什么工具、结果如何验收、失败由谁处理。若成熟产品可以闭环其中大部分高频任务，产品路线获得很强优势。长尾任务不应主导第一版架构。

动作风险

只读搜索、代码修改、发送通知、调整生产配置和资金动作的风险差异很大。风险越高，越需要明确身份、审批、幂等和回执。成熟产品若能接入组织已有控制面，仍然可以使用；如果控制面无法接入，就要把动作降级到人工执行或选择拥有更多执行语义的路线。

状态与生命周期

任务是几秒结束，还是要跨天等待？能否从头重跑，还是必须精确续接？有没有外部副作用？短任务可以容忍简单状态，长任务必须考虑 Schema 版本、恢复、取消和孤儿任务。框架与自建的差距往往在恢复语义，而不是有没有数据库。

集成与部署边界

列出模型、数据、工具和执行器分别位于哪里，哪些内容允许跨边界。成熟产品可能因为部署或数据边界直接出局；框架可能需要自托管；自建也可能继续使用托管模型。路线选择不是简单的“云或本地”。

差异化价值

如果业务价值来自某个领域 Workflow、独特工具或专有数据，使用框架通常能保留差异化，同时复用通用 Runtime。如果价值来自执行隔离、调度、恢复或开发者体验，Harness 本身可能值得自建。团队应把精力投向真正影响产品的层。

团队维护能力

评估未来两年谁维护，不只看首月谁能写出来。需要模型协议、分布式任务、安全、可观测性和评测等多种能力时，一两个应用开发者很难长期覆盖。框架或产品把部分变化转移给供应方，自建则要求稳定的平台 Owner。

可以用权重表组织讨论，但不要让分数制造精确错觉：

维度	权重	产品	框架	自建	证据
真实任务覆盖	25				20 个任务的完成率
权限与审计适配	20				红队与策略测试
长任务恢复	15				重启、升级和超时演练
数据与部署边界	15				架构与合规审查
两年维护成本	15				人力、平台和升级估算
差异化价值	10				产品目标与用户反馈

每个分数后面必须有证据。无法填写证据时，当前任务是做 Spike，不是召开投票会。

八、三种常见误判

产品支持 MCP、Hook 或插件，只说明可以连接外部能力。业务需要的状态、权限和恢复未必能映射到产品生命周期。反过来，框架可以高度自定义，也不意味着应该用它重做成熟产品已经具备的代码 Review、终端和工作区体验。

成熟产品第一天最快，框架几天能搭出流程，自建 Loop 也可能一天跑通。差距会在失败路径出现。正确估算要包含权限、取消、恢复、审计、评测和升级。能跑通一条 Happy Path 只证明模型和工具接上了。

框架和产品都有锁定，自建也会锁定在自己的协议、存储和团队知识上。降低锁定的办法是保留业务契约：任务、状态、工具和证据使用自己的 Schema；把供应方对象限制在 Adapter 内；保存可导出的轨迹；用固定任务集验证替换。提前重写所有基础设施通常比受控适配更贵。

九、从简单路线逐步升级

路线可以演化。系统应该在遇到可复现瓶颈后升级，而不是一开始就为可能出现的规模设计平台。

第一步甚至不是 Agent。固定 Workflow 或一次模型调用能解决的任务，先用简单方案验证价值。Anthropic 的 Agent 设计建议强调只在简单方案不足时增加复杂度，因为 Agent 会用更多延迟与成本换取开放决策能力。

进入产品路线后，把失败记录成结构化样本。产品在哪些任务上完成，在哪些任务上被数据边界、状态或权限阻塞？如果问题只是缺一个工具，优先补 Connector 或 MCP。只有产品生命周期无法表达业务时，再考虑框架。

采用框架后，也不要立刻包装成统一平台。先完成一个垂直流程，测成功率、人工接管率、平均成本和恢复成功率。框架的某个抽象若反复妨碍关键需求，可以在 Adapter 后替换局部组件。只有 Loop、事件或恢复语义本身成为限制，才把对应部分收回自建。

升级也允许回退。一个开放 Agent 若总在固定路径上运行，可以收敛成 Workflow；一个自建 Runtime 若长期只服务标准任务，可以迁回框架；低频任务可以继续交给成熟产品。减少维护面也是架构演进。

十、选型需要一组真实评测

三条路线最终要在相同任务集上比较。只对比 API 和功能，无法知道哪条路线更适合自己的环境。

从历史工单、真实开发任务或业务流程中抽取 20 到 50 个样本，覆盖正常任务、输入缺失、权限不足、工具失败、长任务中断和答案不存在。每个样本写清初始环境、允许动作、验收条件与禁止行为。

任务要包含“拒绝或等待才正确”的案例。Agent 在缺少审批时停下来，在证据不足时说不知道，也属于成功。任务集只有顺利完成的案例，会奖励越权和过度行动。

结果层看任务是否完成、产物是否正确。轨迹层看工具选择、无效循环、越权尝试、恢复路径和证据是否完整。运营层看延迟、Token、外部调用、人工介入和失败后的恢复时间。

成熟产品可能难以暴露所有内部轨迹，这本身就是选型证据。团队要判断现有可观测性是否满足风险等级，而不是为了指标齐全就否定产品。低风险写作任务与生产变更任务需要的轨迹粒度不同。

例如先使用成熟产品完成一个月的代码任务。若高频任务成功率达到目标，数据与权限审查通过，就继续扩展；若超过一定比例的任务因状态或内部系统接入失败，再用框架做一个垂直流程 Spike。框架只有在任务成功率或人工成本上提供显著改进，才进入生产。

退出条件让“自研更灵活”变成可验证假设。没有退出条件，架构升级很容易只进不退。

十一、什么时候三条路线都不该选

有些需求不需要 Agent。步骤固定、规则可编码、错误代价高且没有开放判断空间时，普通程序或 Workflow 更合适。模型可以负责其中一个文本分类或生成节点，整体控制流仍由程序决定。

任务没有客观反馈时也要谨慎。Agent 可以连续生成计划和判断，却无法从环境知道自己是否接近目标，循环只会放大最初偏差。先建设可检查的数据、工具和验收，再谈自主执行。

低频且每次都需要专家判断的流程，人工配合一次模型调用可能更便宜。自动化收益要覆盖开发、运维、审计和失败处理。Agent 能做，不代表值得做成长期系统。

还有一种常见情况：团队缺的是知识整理或系统 API。Agent 读不到准确资料，工具只能返回模糊字符串，再复杂的框架也救不了。先把数据与工具契约补好，通常比换路线有效。

十二、一份可执行的决策流程

准备一张两页以内的 Decision Record，回答下面的问题：

1. 要自动化的具体任务是什么，当前人工流程和成本是多少？
2. 成功、失败、等待和结果未知分别怎样判定？
3. 哪些工具有副作用，身份、审批、幂等和回执在哪里？
4. 哪些数据能进入产品或模型环境，哪些必须留在本地？
5. 三条路线各自覆盖多少真实任务，证据来自哪里？
6. 选择的路线把哪些责任交给供应方，哪些留给团队？
7. 谁维护状态、权限、执行、观测、评测和升级？
8. 何种失败会触发下一条路线，何种结果会让项目退回简单方案？

然后做最小验证：

• 产品路线连接一个真实工作空间，完成五个有验收条件的任务；
• 框架路线只实现一条垂直流程，包含一次中断和恢复；
• 自建路线先做一个只读工具，验证事件、状态和错误语义，再开放副作用。

三次验证都使用相同任务和指标。两周后，团队讨论的是轨迹、失败和维护责任，而不是 Demo 观感。

十三、我的选择顺序

我会把成熟产品放在第一顺位。它能最快证明任务有没有价值，也能让团队提前看到需要哪些工具、规则和验收。产品边界足够时，继续使用产品是合理的工程选择。

确认需要自定义业务状态后，再选一个抽象层贴近问题的框架。图状态、事件 Runtime、类型化工具和多 Agent 团队解决的是不同问题，框架名称不应先于问题出现。Spike 要主动测试恢复和失败，正常路径没有区分度。

只有当团队能够指出框架阻碍了哪条关键语义，并且愿意长期维护运行时，我才会建议自建 Harness。自由度只是结果，责任才是成本。一个小而透明、覆盖明确任务的自建 Harness，比面向所有场景的平台更容易活下来。

三条路线可以同时存在。成熟产品服务标准工作，框架承载定制业务流程，自建 Harness 处理少数必须拥有底层语义的任务。每一层责任都应有明确且合适的承担者。

参考资料

• Anthropic：Building effective agents
• Anthropic：Writing effective tools for AI agents
• Anthropic：Demystifying evals for AI agents
• Claude Code：How Claude Code works
• OpenAI Codex 官方仓库
• OpenClaw：Gateway Architecture
• LangGraph Overview
• AutoGen 官方文档
• Pydantic AI Agents
• CrewAI Crews
• Learn Claude Code 官方仓库
• Pi 官方仓库