--- title: "AI Platform 的抽象边界：复杂度最终由谁承担？" author: "Shawn Jiang" lang: zh date: 2026-09-16 canonical: https://tplog.dev/zh/essay/ai-platform-abstraction-boundary/ translations: en: https://tplog.dev/en/essay/ai-platform-abstraction-boundary/ ja: https://tplog.dev/ja/essay/ai-platform-abstraction-boundary/ --- # AI Platform 的抽象边界：复杂度最终由谁承担？ 最近我在用 Factory。 如果说 Claude Code 更像一个能力很强的 Coding Agent，那么 Factory 想做的事情更大：把软件研发组织成一套由 Agent 驱动的生产系统。它不只帮助工程师写代码，还试图覆盖规划、实现、测试和审查；对于更大的任务，[Missions](https://docs.factory.ai/missions/overview) 会负责拆解工作、调度 Worker，并在里程碑结束时安排 Validator 验证结果。 这套设计背后有一个问题：平台是在替用户吸收复杂度，还是把原来的复杂度换成了另一套需要学习的概念？ ## Dify 降低了哪一种门槛 第一次接触 Dify 时，很多东西都很直观。拖几个节点，接入模型和知识库，再加上需要的工具，很快就能搭出一个 AI 应用。相比从头写代码，门槛确实低了很多。 但进入企业环境后，另一部分复杂度会逐渐出现。 使用者需要理解 Workflow、Agent、检索增强生成（RAG）、变量、工具调用、知识库和模型差异。进入私有化部署，还要处理 Kubernetes、数据库、网络、权限、版本升级、插件和 License。 Dify 降低了构建 AI 应用的起始门槛，却没有让这些应用在真实环境中的复杂度消失。它只是重新划分了复杂度：一部分被平台吸收，另一部分变成了使用和运维 Dify 所需的知识。 这不一定是产品设计出了问题。企业软件本来就要面对权限、安全、稳定性和集成，平台不可能凭空消除它们。真正值得观察的是：哪些复杂度必须由用户理解，哪些会随着产品成熟被继续吸收？ ## 用同一个框架观察 Factory Factory 比从头搭建一套 Agent System 简单得多。Missions 已经把规划、执行和验证组织成了一条完整路径，系统也提供内置的 Worker 和 Explorer。Subagent 默认可以继承主会话的模型和推理强度，也可以按照任务复杂度选择模型。对于简单任务，官方文档则建议直接使用普通会话，不必启动 Mission。 从这些默认设置和内置角色可以看出，Factory 并没有把编排能力全部丢给用户，也在尝试为不同任务提供一条可以直接使用的路径。 继续用下去，使用者仍然会遇到一组新的选择： 哪个模型适合 Orchestrator，哪个适合 Worker？ Validator 应该使用能力更强的模型，还是成本更低的模型？ Reasoning Effort 应该开到什么程度？ 什么任务值得拆给 Subagent，什么任务更适合让一个 Agent 连续完成？ 对于喜欢研究 Agent System 的人，这些问题很有意思，更多控制权甚至是产品吸引力的一部分。但大部分用户真正想解决的问题，可能只是“帮我修掉这个 Bug”，或者“让这个需求更快进入生产环境”。他们关心交付，不一定想先成为模型和编排专家。 ## 平台化不等于简单化 平台的自然冲动，是把能力暴露出来。只有允许用户配置节点、模型、Worker 和验证方式，平台才能覆盖足够多的场景，也才能服务最早的一批专业用户。 所以，早期的复杂并不可怕。Kubernetes、Terraform 和 Datadog 也不是一开始就容易使用。专业工具首先要让能力成立，然后才有机会根据真实使用吸收复杂度。 真正优秀的平台，最终要把今天暴露给用户的复杂度重新吸收回去。 现在需要用户自己选择的模型，以后可以由系统根据任务和风险自动 Routing；任务是否拆分、怎样组织 Worker，也可以由系统判断。Validation 同样如此：验证强度应该取决于改动范围和失败代价，不一定每次都由用户从头设计。 Factory 已经能通过内置 Worker、模型继承和复杂度分级减少一部分选择。Missions 也在替用户组织原本需要手工搭建的多 Agent 协作。问题不是它有没有开始吸收复杂度，而是这条路最终可以走多远。 ## 让用户描述约束，而不是实现 一个成熟的 AI 产品，不应该要求用户越来越懂模型，而应该帮助用户越来越准确地表达自己的问题。 例如，用户只需要说明： 这是一个生产环境中的 Bug。 优先保证质量。 两小时内完成。 成本不是第一优先级。 至于是否拆分 Subagent、启动几个 Worker、选择哪个模型、何时验证，以及失败后是否升级模型，都可以由系统根据这些约束决定。 用户真正关心的没有太大变化：结果好不好，速度快不快，成本高不高。底层用了哪个模型、多少个 Agent、怎样编排，本质上都是实现手段。如果用户必须先理解这些手段，才能稳定获得结果，说明产品的抽象仍有继续演化的空间。 使用这个产品之前，需要学习多少只属于它的概念？ 如果用户学习的是自己的业务，例如软件工程、销售、客服或法律，这些知识可以直接改善判断。但如果大量时间花在理解 Node、Worker、Mission、Validator、Router 和 Context Strategy，产品就仍然把不少内部复杂度留给了用户。 配置不必全部消失。专业用户需要调试入口，企业也需要控制成本、安全和模型合规。好的抽象应该让大多数人不必配置也能得到可靠结果，同时保留必要的介入方式。 判断一个 AI Platform，要看它最终能替用户吸收多少复杂度，而不只是暴露了多少能力。 Factory 让我觉得有意思的地方，恰恰是这个问题还远没有结束。 ## 资料来源 - [Factory Missions](https://docs.factory.ai/missions/overview) - [Factory Missions Configuration & Reference](https://docs.factory.ai/missions/reference) - [Factory Custom Droids（Subagents）](https://docs.factory.ai/harness/subagents)