企业官网建设流程全解析

1. 从“助手”到“交易标的”：AI代理化的底层逻辑

过去两年，我们习惯把AI当成一个“更聪明的搜索框”或者“会写代码的实习生”。你问它答，它帮你补全函数、润色邮件、总结会议纪要。这个阶段的AI，本质上是工具，是助手，是被动响应的。

但最近半年，圈子里讨论的风向变了。大家不再只关心“哪个模型跑分高”，而是开始琢磨“怎么让AI自己调用工具、自己拆解任务、自己完成闭环”。这就是AI代理和AI平台开始被市场当作独立交易标的的根本原因。

我最早接触这个概念是在一个自动化运维项目里。当时的需求很简单：每天凌晨自动巡检服务器、发现异常日志就触发修复脚本、修复失败再通知值班人员。传统做法是写一堆crontab加shell脚本，但维护成本极高，稍微换个环境就全废。后来尝试用大模型做决策中枢，把“巡检-判断-修复-上报”拆成四个可调用的工具，让模型根据实时状态决定下一步调哪个工具。跑通之后我发现，这套东西的价值远不止省了几个脚本——它变成了一个可以独立运行、可以对外提供服务、可以按次计费的实体。

这就是代理和平台的区别。代理是“能自己干活的AI”，平台是“能让一堆代理协同干活的AI”。市场开始交易这两样东西，意味着AI从“按token卖算力”进入了“按任务完成度卖结果”的新阶段。

1.1 为什么“代理”比“助手”更值钱

助手模式下，用户需要自己拆解任务、自己判断结果对不对、自己决定下一步做什么。代理模式下，用户只需要给一个目标，剩下的由代理自己规划、执行、验证、迭代。

我拿Codex这类代码生成工具举例。早期用法是“帮我写一个Python函数，输入是列表，输出是去重后的列表”。这是助手。现在的用法是“把这个项目的单元测试覆盖率从60%提到85%，跑通所有CI”。这是代理。前者按次收费几毛钱，后者按项目收费几百到几千块，差距就在这里。

代理值钱的地方在于它承担了决策责任。它不仅要生成内容，还要判断生成的内容能不能用、要不要重试、要不要换方案。这个“判断”本身就需要调用外部工具、访问实时数据、维护状态机。一旦代理能稳定完成这些，它就可以被封装成API、被编排进工作流、被当作独立服务交易。

1.2 平台化：从单点代理到代理网络

单个代理再强，也有边界。一个写代码的代理搞不定部署，一个做数据分析的代理搞不定前端展示。于是平台出现了。

平台的核心价值不是“提供更强的模型”，而是提供代理之间的协作协议。比如一个电商场景：选品代理负责爬数据找爆款，文案代理负责生成商品描述，设计代理负责出图，客服代理负责回答售前问题。这四个代理可能来自不同团队、用不同模型、跑在不同机器上。平台要做的是定义它们之间怎么传数据、怎么处理失败、怎么分账。

我见过一个比较成熟的实现方案：用消息队列做代理间通信，每个代理注册自己的“能力描述”，平台根据任务类型路由到对应代理。代理执行完把结果写回队列，由下一个代理消费。整个链路对用户透明，用户只看到一个“帮我上架这个商品”的按钮。

这种平台一旦跑通，交易属性就非常明显了。你可以按代理调用次数收费，可以按任务完成量抽成，也可以把优质代理打包成订阅服务。市场交易的标的从“模型API”变成了“代理能力”和“平台路由权”。

2. 代理与平台的核心技术拆解

2.1 代理的四大核心模块

一个能稳定干活的代理，至少包含四个部分：规划器、执行器、记忆体、验证器。

规划器负责把用户目标拆成子任务。比如“帮我订一张明天去北京的机票”，规划器要拆成“查航班-比价格-选座位-填乘机人-支付”。这一步通常用大模型做few-shot推理，但要注意：不要让模型直接输出最终答案，而是输出结构化的任务列表。我习惯用JSON schema约束输出格式，每个子任务包含“工具名、参数、依赖关系”。

执行器负责调用具体工具。工具可以是HTTP API、本地脚本、数据库查询、甚至另一个代理。这里有个坑：工具调用必须做超时和重试。我遇到过代理卡在一个不响应的API上整整三分钟，最后整个任务超时。后来加了熔断机制，单个工具超过5秒没响应就跳过，记录日志继续下一步。

记忆体负责维护上下文。短期记忆是当前任务的执行历史，长期记忆是用户偏好和历史任务结果。短期记忆用队列就行，长期记忆建议用向量数据库。但要注意：不是所有历史都要存。我试过把每次工具调用的完整返回都塞进上下文，结果token爆炸，模型反而变笨了。后来改成只存“关键决策点”和“最终结果”，效果反而更好。

验证器负责判断子任务是否完成。最简单的验证是检查返回状态码，但很多场景需要语义验证。比如“生成一段商品描述”，状态码是200不代表描述合格。这时候需要另一个模型做质量打分，或者用规则引擎检查关键词覆盖。验证不通过就触发重规划，这是代理区别于普通脚本的关键。

2.2 平台的路由与编排机制

平台要解决的核心问题是：给定一个任务，怎么找到最合适的代理组合。

最粗暴的做法是维护一个代理列表，每个代理标注能力标签，任务来了就按标签匹配。但实际场景往往需要多个代理串联。比如“分析竞品并生成报告”，需要爬虫代理、分析代理、写作代理、排版代理。平台要能自动编排这个链路。

我目前看到比较靠谱的方案是基于DAG的编排。每个代理声明自己的输入输出格式，平台根据任务目标反向推导需要哪些代理、按什么顺序执行。执行过程中如果某个代理失败，平台要能决定是重试、跳过还是回滚。

这里有个经验：编排层不要做太重的逻辑。我见过一个平台把业务规则全写在编排层，结果每加一个代理就要改编排代码，维护成本极高。后来改成代理自己声明“前置条件”和“后置效果”，平台只做匹配和调度，扩展性好了很多。

2.3 代理间通信的数据格式设计

代理之间传什么，直接决定了平台能不能规模化。

早期我试过让代理直接传自然语言，比如爬虫代理返回“我找到了三个竞品，分别是A、B、C”。下游代理要解析这句话，非常不稳定。后来改成强制JSON schema，每个代理的输出必须符合预定义结构。爬虫代理返回{"competitors": [{"name": "A", "price": 100}, ...]}，下游直接按字段取。

但JSON也有问题：字段名冲突。不同代理可能用不同命名习惯，有的叫product_name，有的叫title。平台层需要做字段映射，或者强制统一命名规范。我的做法是维护一个“领域词典”，所有代理必须从词典里选字段名，新字段需要申请。听起来麻烦，但后期省了大量调试时间。

3. 从零搭建一个可交易的代理平台：实操记录

3.1 环境准备与基础依赖

我用的技术栈比较朴素：Python做代理逻辑，FastAPI做接口，Redis做消息队列，PostgreSQL存任务状态，MinIO存文件。模型侧用OpenAI兼容接口，方便切换不同后端。

先装依赖：

pip install fastapi uvicorn redis psycopg2-binary minio openai pydantic

Redis和PostgreSQL用Docker起，省得配环境：

docker run -d --name redis -p 6379:6379 redis:7-alpine docker run -d --name pg -p 5432:5432 -e POSTGRES_PASSWORD=secret postgres:15-alpine

MinIO也起一个，用来存代理生成的中间文件：

docker run -d --name minio -p 9000:9000 -p 9001:9001 minio/minio server /data --console-address ":9001"

这些基础组件跑起来之后，先别急着写代理。先定义任务状态机。我定义的状态有：pending、planning、executing、verifying、completed、failed。每个状态之间的转换条件写清楚，后面调试会轻松很多。

3.2 代理注册与能力声明

每个代理启动时向平台注册，声明自己的能力和输入输出格式。我用一个简单的HTTP接口：

from fastapi import FastAPI from pydantic import BaseModel class AgentRegistration(BaseModel): agent_id: str capabilities: list[str] input_schema: dict output_schema: dict endpoint: str app = FastAPI() @app.post("/register") def register(reg: AgentRegistration): # 存到数据库，同时更新内存中的路由表 save_agent(reg) update_routing_table(reg) return {"status": "ok"}

能力声明要具体。不要写“能处理文本”，要写“能提取网页正文并返回标题、作者、发布时间”。越具体，路由越准。

我踩过一个坑：代理注册后没有心跳机制。有个代理进程挂了，平台还在往它发任务，结果任务全部超时。后来加了定时心跳，超过30秒没心跳就标记为不可用，路由时自动跳过。

3.3 任务规划器的实现细节

规划器是整个平台最核心的部分。我的实现思路是：用大模型做任务拆解，但用代码做任务校验。

先定义任务模板：

class SubTask(BaseModel): task_id: str tool_name: str params: dict depends_on: list[str] = [] status: str = "pending"

然后调模型生成子任务列表：

def plan_task(goal: str) -> list[SubTask]: prompt = f""" 用户目标：{goal} 可用工具：{get_available_tools()} 请拆解为子任务，输出JSON数组，每个子任务包含tool_name、params、depends_on。 只输出JSON，不要其他内容。 """ response = call_llm(prompt) subtasks = parse_json(response) validate_subtasks(subtasks) # 检查工具是否存在、依赖是否有环 return subtasks

validate_subtasks很关键。模型经常生成不存在的工具名，或者依赖关系成环。我加了三个检查：工具名必须在注册表里、依赖的task_id必须存在、依赖图不能有环。不通过就重新规划，最多重试三次。

3.4 执行器的并发与容错

执行器我用了asyncio做并发。每个子任务是一个协程，依赖满足就启动。

async def execute_task(task: SubTask): try: result = await call_tool(task.tool_name, task.params, timeout=10) task.status = "completed" task.result = result except TimeoutError: task.status = "failed" task.error = "timeout" except Exception as e: task.status = "failed" task.error = str(e) finally: await notify_dependents(task)

超时设10秒是经验值。大部分工具调用在3秒内完成，10秒还没响应基本就是挂了。失败的任务不会阻塞整个流程，依赖它的子任务会被标记为skipped，最终任务状态是partial。

这里有个细节：结果要落盘。我见过代理跑完任务结果只存在内存里，进程一重启全没了。现在每个子任务完成后，结果同时写Redis和PostgreSQL，Redis做快速读取，PostgreSQL做持久化。

3.5 验证器的规则与模型混合策略

验证器我用了两层：第一层是规则验证，第二层是模型验证。

规则验证检查基本条件：返回是否为空、字段是否齐全、数值是否在合理范围。比如爬虫代理返回的价格如果是负数，直接判定失败。

模型验证用于主观判断。比如“生成一段商品描述”，规则只能检查长度和关键词，但描述是否通顺、是否有吸引力需要模型打分。我用的prompt是：

请对以下商品描述打分，1-10分，只输出数字。 描述：{description}

低于6分就触发重规划。但要注意：模型验证本身也有成本。我一开始每个子任务都做模型验证，结果token消耗翻了三倍。后来改成只对关键子任务做模型验证，比如最终输出、涉及金额的计算，中间步骤用规则验证就够了。

4. 代理平台落地中的常见问题与排查实录

4.1 代理“假死”与心跳超时

现象：任务卡在executing状态不动，日志显示代理已接收任务但没有返回。

排查：先看代理进程是否存活，再看代理是否在等外部API响应。我遇到过一次是代理调用的第三方接口挂了，但代理没有设超时，一直等。

解决：代理侧所有外部调用必须设超时，平台侧加心跳检测。心跳超时后，平台把任务重新入队，换一个代理实例执行。同时记录该代理的失败次数，连续失败三次就下线。

4.2 任务规划结果不稳定

现象：同样的目标，模型每次拆解的子任务数量不一样，有时候3个，有时候8个。

排查：模型温度设太高，或者prompt里没有约束子任务数量。

解决：温度降到0.2，prompt里加一句“子任务数量控制在3-6个”。另外，我在规划后加了一个“合并”步骤：如果两个子任务调用同一个工具且参数相似，就合并成一个。

4.3 代理间数据格式不兼容

现象：上游代理返回的字段名是product_title，下游代理期望的是title，导致下游解析失败。

排查：没有统一的字段命名规范。

解决：维护一个领域词典，所有代理注册时必须从词典选字段。新字段需要走审批流程。同时平台层加一个字段映射层，兼容历史代理。

4.4 平台性能瓶颈

现象：并发任务超过50个时，任务调度延迟明显增加。

排查：路由表在内存里用列表遍历，O(n)复杂度。代理数量到200个时，每次路由要遍历200次。

解决：路由表改成倒排索引，能力标签到代理ID的映射用哈希表。同时把任务队列从Redis List改成Redis Stream，支持消费者组，多个调度器实例可以并行消费。

4.5 常见问题速查表

5. 代理与平台交易的商业模式思考

5.1 按任务计费与按结果计费

代理平台最直接的变现方式是按任务计费。用户提交一个任务，平台根据任务复杂度报价。简单任务比如“提取网页正文”收几分钱，复杂任务比如“生成竞品分析报告”收几块钱。

但按任务计费有个问题：用户不知道任务到底要跑多久、消耗多少资源。我试过按token消耗计费，但用户看不懂。后来改成“基础费+超额费”：基础费覆盖前30秒和10次工具调用，超出部分按量加收。用户能理解，平台也不亏。

更激进的是按结果计费。比如“把代码覆盖率提到85%”，达不到不收费。这种模式对代理质量要求极高，但一旦跑通，客单价可以高很多。我目前只在内部项目试过，对外还不敢承诺。

5.2 代理市场的抽成模式

如果平台允许第三方代理接入，抽成是自然选择。我设的抽成比例是15%，代理开发者拿85%。但抽成之外，平台还要提供质量保障：代理失败要赔付、代理超时要补偿。这部分成本要从抽成里出。

我见过一个平台把抽成定到30%，结果优质代理全跑了。15%左右比较合理，既能覆盖平台运营，又不至于让开发者觉得被剥削。

5.3 平台间的代理互操作

现在每个平台都有自己的代理注册协议，互不兼容。如果用户想用一个平台的爬虫代理加另一个平台的分析代理，做不到。

我目前的做法是提供适配层：平台A的代理通过适配器注册到平台B，能力声明做映射。但这只是权宜之计。长期看需要行业级的代理描述标准，类似OpenAPI之于REST API。不过标准制定不是小团队能推动的，先把自己的平台跑稳再说。

6. 个人实操体会与后续扩展方向

这套代理平台我断断续续搞了快一年，踩的坑比写过的代码还多。最大的体会是：代理的智能程度不取决于模型多强，而取决于失败处理做得多细。模型再聪明，遇到API超时、字段缺失、依赖成环照样抓瞎。反而是那些把重试、熔断、降级、补偿做扎实的代理，跑起来更稳。

另一个体会是：平台不要试图做所有事。我一开始想把规划、执行、验证、存储全自己写，结果每个模块都半吊子。后来把存储交给PostgreSQL、队列交给Redis、文件交给MinIO，自己只专注规划器和路由层，进度快了很多。

后续我打算在这几个方向继续折腾：一是代理的自我进化，让代理根据历史执行记录自动调整规划策略；二是跨平台代理编排，把不同来源的代理统一调度；三是代理性能画像，给每个代理打上“速度分”“质量分”“成本分”，路由时根据任务需求自动选最优代理。

如果你也在搞类似的东西，我的建议是：先从单代理跑通闭环，再考虑平台化。单代理都跑不稳，平台化只会把问题放大。另外，日志一定要打全，每个子任务的输入输出、耗时、状态都记下来，出问题的时候能省大量排查时间。