企业官网建设流程全解析

1. 从 Manus 爆火说起：Workflow 和 Agent 到底差在哪

Manus 刷屏那几天，我朋友圈里做自动化的、做 RPA 的、做 LLM 应用的都在转。有人兴奋地说"Agent 时代真的来了"，也有人泼冷水说"这不就是把工作流包装了一下"。这两种声音其实都指向同一个问题：Workflow（工作流）和 Agent（智能体）的边界到底在哪。

如果你正在选型一个自动化方案，或者想把现有脚本升级成"带脑子"的系统，这个问题不搞清楚，很容易走弯路。我见过太多团队花两周搭了一套 Agent 框架，最后发现业务场景其实用 GitHub Actions 加几个条件分支就够了；也见过有人硬用工作流去处理开放式对话，结果写了一百多个 if-else 还是兜不住。

先把两个概念用一句话钉死：

• Workflow：一条预先设计好的执行路径，步骤、依赖、触发条件都是人写死的。它像地铁线路图，从 A 站到 B 站怎么走是确定的。
• Agent：一个能感知输入、自主决策、调用工具、根据结果调整下一步的实体。它像出租车司机，你说目的地，路线他自己判断。

Manus 之所以让人眼前一亮，是因为它把"自主规划 + 工具调用 + 多步执行"这套 Agent 能力做得足够顺滑，用户只给一个模糊目标，它自己拆任务、自己找工具、自己判断做完了没有。但如果你仔细看它的执行轨迹，会发现底层依然有大量工作流式的编排在兜底——这就是当下最真实的形态：Agent 负责决策，Workflow 负责稳定执行。

这篇文章不聊虚的，我会从任务编排、决策自主性、工具调用边界三个角度把差异拆开，然后给你可复制的配置示例，最后说清楚 TaoToken 的统一 Key/API 通道在这两类架构里分别接在哪一层。适合正在做 AI 应用选型的开发者、想把内部流程自动化的工程师，以及刚接触 Agent 概念想动手试的人。

2. TaoToken 前置准备：统一 Key 与 API 通道怎么接

不管你最后选 Workflow 还是 Agent，只要涉及调用大模型，就绕不开三件事：Base URL、API Key、Model ID。这三件套配错一个，后面全是 401 和超时。TaoToken 的价值就在于把这三件事统一成一套通道，Workflow 里的单步调用和 Agent 里的多轮工具调用走同一个入口，省得你在不同框架里维护多份凭证。

先说清楚接入位置。在 Workflow 架构里，TaoToken 通常出现在"需要模型判断"的那一个节点上，比如分类节点、摘要节点、生成节点，它是流程中的一个环节。在 Agent 架构里，TaoToken 是 Agent 的"大脑接口"，每一轮 Observe-Decide-Act 循环都要经过它，调用频率高、并发要求也更高。

前置准备分三步走。

第一步，拿到 API Key。访问控制台创建密钥，路径是 console 页面，创建后立刻复制保存，页面刷新就不再完整显示。这个 Key 就是后面所有配置里的sk-开头那串。

第二步，确认 Base URL。TaoToken 的 API 入口是https://taotoken.net/api，注意这里不带任何查询参数，配置时直接填这个根地址，具体路径由各框架自己拼接。很多人配错就是因为多加了/v1或者少了斜杠，后面排障章节我会专门讲。

第三步，选 Model ID。不同框架对模型名的写法要求不一样，有的要claude-sonnet-4-5，有的要带前缀。建议先在模型对话页面手动发一条消息验证通道通了，再去配代码。这一步能帮你排除掉 80% 的"到底是 Key 错还是模型名错"的纠结。

如果你用的是 Claude Code 这类编码 Agent，配置方式又不一样，它读的是环境变量和 settings 文件。下面章节我会分别给出 Workflow 场景（以 JSON 配置为例）和 Agent 场景（以 Claude Code settings 为例）的可复制片段。

提示：Key 只创建一次就够，Workflow 和 Agent 共用同一个 Key，不需要为不同架构单独申请。这样做的另一个好处是账单和调用量统计集中在一处，排查异常调用时不用来回切换。

3. 可复制配置：Workflow 与 Agent 的 settings 片段

这一节直接上配置。我按两种架构分别给，你可以对照自己的场景抄。

3.1 Workflow 场景：JSON 节点配置

假设你用的是一个支持 JSON 定义节点的编排工具（Airflow、Dify、n8n 都类似），模型节点大概长这样：

{ "node_id": "classify_intent", "type": "llm", "provider": "openai_compatible", "config": { "base_url": "https://taotoken.net/api", "api_key": "${TAOTOKEN_API_KEY}", "model": "claude-sonnet-4-5", "temperature": 0.2, "max_tokens": 1024 }, "input": "{{user_query}}", "output_key": "intent_label", "next": { "refund": "handle_refund", "query": "handle_query", "default": "handle_fallback" } }

注意几个点。base_url填根地址，不要自己加/v1/chat/completions，框架会拼。api_key用环境变量引用，别硬编码进 JSON，提交到仓库就泄露了。temperature设低一点，Workflow 里的模型节点通常要的是稳定分类结果，不是创意输出。next字段就是工作流的灵魂——决策路径是写死的，模型只负责打标签，走哪条路由由配置决定。

3.2 Agent 场景：Claude Code settings 配置

如果你用的是 Claude Code 这类编码 Agent，它读的是 settings 文件。三件套要写全：

{ "env": { "ANTHROPIC_BASE_URL": "https://taotoken.net/api", "ANTHROPIC_API_KEY": "sk-你的Key", "ANTHROPIC_MODEL": "claude-sonnet-4-5" }, "permissions": { "allow": ["Read", "Edit", "Bash(git*)"] } }

这个文件一般放在项目根目录的.claude/settings.json，或者用户级的~/.claude/settings.json。ANTHROPIC_BASE_URL指向 TaoToken 的 API 根地址，ANTHROPIC_API_KEY填你的 Key，ANTHROPIC_MODEL指定模型 ID。三个都写全，缺一个就会走到默认端点然后报错。

permissions这块是 Agent 特有的——工具调用边界在这里定义。allow列表里写它能用哪些工具，没写的默认要询问。这就是 Agent 和 Workflow 在配置层面最直观的差异：Workflow 的边界写在next路由里，Agent 的边界写在permissions里。

3.3 两种配置的对照

配好之后别急着跑复杂任务，先用一个最小请求验证通道。下一节给验证动作。

4. 验证请求：确认通道通了再上业务

配置写完，第一件事是验证。我习惯用 curl 先打一发，排除掉框架层的干扰。

curl https://taotoken.net/api/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $TAOTOKEN_API_KEY" \ -d '{ "model": "claude-sonnet-4-5", "messages": [{"role": "user", "content": "回复两个字：通了"}], "max_tokens": 32 }'

预期返回是一个标准 JSON，choices[0].message.content里应该有"通了"两个字。如果这一步就失败，别往下走，先看报错信息对号入座。

通道验证通过后，再验证 Workflow 的路由逻辑。构造三条输入，分别命中三个分支：

# 命中 refund 分支 curl -X POST http://localhost:8080/run \ -d '{"user_query": "我要退款"}' # 命中 query 分支 curl -X POST http://localhost:8080/run \ -d '{"user_query": "订单到哪了"}' # 命中 default 分支 curl -X POST http://localhost:8080/run \ -d '{"user_query": "今天天气怎么样"}'

看返回的intent_label是不是分别落到refund、query、default。如果三条都落到同一个分支，说明模型节点没生效，大概率是 Key 或 Base URL 配错，模型返回了空或者报错，路由走了默认值。

Agent 的验证方式不同，它没有固定分支，你要验证的是"它会不会自己选工具"。给一个需要多步的任务，比如"把当前目录下所有 .log 文件里的 ERROR 行提取出来存到 errors.txt"，然后观察它的执行轨迹。正常的 Agent 会先列目录、再读文件、再写文件，每一步都通过 TaoToken 调用模型做决策。如果它卡在第一步不动，或者反复调用同一个工具，说明工具边界配置有问题，回去检查permissions.allow。

实测下来，验证环节最容易被跳过，但恰恰是它帮你把"配置错误"和"逻辑错误"分开。通道不通是配置问题，通道通了但行为不对才是逻辑问题，两者的排查方向完全不同。

5. 常见报错排查：401、local proxy failed、reading choices

这一节按真实报错来。我把踩过的坑列出来，你对照着看。

401 Unauthorized。最常见，原因就三个：Key 没填、Key 填错、Key 前面多了空格。检查Authorization头是不是Bearer sk-xxx格式，Bearer 和 Key 之间一个空格，Key 后面不能有换行。如果你用的是环境变量，echo $TAOTOKEN_API_KEY看一眼是不是空的。

local proxy failed / connection refused。这个报错通常出现在你本地起了代理层，但代理没起来或者端口不对。检查你的base_url是不是被某个本地工具改写成了http://localhost:xxxx。正确做法是直接指向https://taotoken.net/api，不要经过本地转发。如果你确实需要本地代理做日志，确认代理进程在跑，端口和配置一致。

reading choices 相关报错，比如cannot read property 'choices' of undefined或者reading '0'。这是典型的响应结构不符合预期。原因一般是 Base URL 配错了路径，比如你填了https://taotoken.net/api/v1，框架又拼了一次/v1/chat/completions，变成/api/v1/v1/chat/completions，返回 404 的 HTML，解析choices自然就崩了。解决方法是 Base URL 只填到/api，让框架自己拼路径。

OAuth 相关报错。如果你用的是 Claude Code 并且看到 OAuth 字样，说明它没走 API Key 而是尝试走账号登录流程。检查 settings 里ANTHROPIC_API_KEY是不是没生效，或者被系统环境变量覆盖了。Claude Code 优先读环境变量，其次读 settings 文件，两处都检查一遍。

模型名不识别。报错类似model not found。检查 Model ID 拼写，不同框架对模型名的要求不同，有的要全称有的要简称。最稳的办法是先在模型对话页面确认这个模型能用，再抄名字。

注意：排障时把日志级别调到 debug，能看到实际请求的 URL 和 headers。90% 的问题看一眼实际 URL 就明白了。

如果上面这些都对完了还是不通，去接入文档页面按步骤重新走一遍，或者直接在模型对话里发消息确认账号状态。文档里有各框架的完整配置示例，比对着抄不容易错。

6. 选型建议与接入入口

回到最初的问题：什么时候用 Workflow，什么时候用 Agent。

我的判断标准很简单，看任务路径是否可枚举。如果所有可能的执行路径你都能提前画出来，用 Workflow，稳定、便宜、好调试。如果路径数量不确定，或者需要根据中间结果动态决定下一步，用 Agent。Manus 这类产品之所以用 Agent，就是因为用户给的目标太开放，没法预先枚举路径。

但真实系统往往是混合的。我的建议是：用 Workflow 做骨架，用 Agent 做关节。骨架负责流程的确定性和可观测性，关节负责在关键节点上做智能决策。比如一个客服系统，整体流程（接入-分类-处理-归档）用 Workflow，分类节点和回复生成节点用 Agent 能力。这样既拿到了稳定性，又保留了灵活性。

接入层面，两类架构共用同一套 TaoToken 通道。Workflow 的模型节点、Agent 的决策循环，都指向同一个 Base URL 和同一个 Key。想先验证模型效果，去模型对话页面手动试几条；准备长期跑编码类 Agent 任务，看 Coding Plan 页面；需要创建和管理 Key，去 API Keys 页面；配置过程中卡住了，接入文档里有各框架的完整示例。

选型不是一次性的决定，先跑起来，用真实数据验证，再调整。Workflow 和 Agent 的边界会随着你对业务的理解越来越清晰。