企业官网建设流程全解析

这次我们来看一套偏向工程落地的 Agent 实战项目体系：Multi Agent + Harness + Tools + MCP + Skills，项目方是码士集团。项目重点不是堆概念，而是把多智能体协作、工具调用、上下文管理、标准化服务接入、技能沉淀这几个模块串成一条完整链路，并且用 AI 职业规划这个真实场景做演示载体。如果你正在做 Agent 开发、想搞懂 Harness 和 MCP 在项目里到底怎么用，或者准备搭建一套自己的多智能体工作流，这篇文章可以直接收藏。

内容定位很明确：先给规格和结构，再给一套可以照着改的部署和测试思路。整个项目围绕“让多个 Agent 协作完成一个复杂任务”展开，核心不是某个单点模型多强，而是工程体系是否完整。材料里没有提供公开发布的下载地址和精确参数，所以下文所有命令和代码都会标记为通用模板。我们重点解决下面这些问题：多 Agent 之间怎么分工、Harness 怎么约束 Agent 的执行循环、Tools 怎么统一注册和调用、MCP 服务怎么接入、Skills 怎么沉淀成可复用的能力。

1. 核心能力速览

先从整体架构角度看这个项目的技术栈。标题里五个关键词构成了完整的 Agent 工程链路，下面用一张表拆开。

从功能范围看，这更像一套“Agent 系统模板”，而不是单一模型。它的核心卖点可以归纳为四点：

• 角色化分工：不同 Agent 各司其职，由主控 Agent 调度。
• 可插拔工具：Tools 统一注册，MCP 统一协议，接入新服务不用改主逻辑。
• 能力沉淀：Skills 把常见任务固化成模块，下次直接加载。
• 场景落地：用 AI 职业规划作为实战样例，演示多 Agent 的完整协作流程。

硬件门槛方面，这类项目主要依赖大模型推理服务。如果你的模型通过 API 调用，那么一台普通开发机就够跑完整框架；如果要本地部署模型或做微调，就需要单独评估 GPU 和显存。具体显存占用没有公开数据，需要以实际模型版本和推理参数为准。

2. 适用场景与使用边界

这套体系适合谁？首先是做 AI 应用开发的工程师，想从“单轮 Prompt 调用”升级到“多 Agent 协作系统”。其次是技术团队负责人在做技术选型，需要评估 Multi Agent、MCP、Skills 这些概念适不适合自己的业务。最后是研究型开发者，想对比不同 Agent 框架的工程差异。

典型应用场景包括：

• 复杂信息搜集与整理：由多个 Agent 分头搜集行业、岗位、技能要求，再汇总生成报告。
• 职业规划咨询：通过多 Agent 协作，从个人背景、市场需求、能力差距三个维度做诊断。
• 企业内部知识库问答：连接企业内部文档和数据服务，Agent 完成任务时自动检索相关资料。
• 批量文本生产：多个 Worker Agent 并行生成内容，再由 Review Agent 审核并修订。
• 自定义工具工作流：通过 MCP 接入办公软件、在线文档、低代码平台，形成自动化链路。

边界也很重要。这套架构不是必需的。如果任务只是“单次问答”或者“调用一个 API”，没必要引入 Multi Agent，反而增加延迟和出错概率。多 Agent 系统的成本包括：Token 消耗成倍增加、调试复杂度上升、任务失败时定位困难。

合规方面必须强调：Agent 在调用工具获取数据时，要确认数据来源的合法性和授权范围。涉及用户个人职业信息、简历数据时，要做好隐私保护。项目如果商用，还要检查模型服务条款是否允许用输出结果训练或商用。涉及人脸、声音、肖像等敏感能力的项目，必须有明确授权；即使本项目的职业规划场景不涉及，也要在工程化过程中养成版权和隐私审查习惯。

3. 环境准备与前置条件

在没有公开一键包的情况下，我们自己搭一套同类型项目，需要先把基础环境准备好。下面给的是通用清单，具体版本以实际项目 README 为准。

3.1 基础运行环境

• 操作系统：Windows 10/11、Ubuntu 20.04+、macOS 12+ 都可以。
• Python 版本：建议 3.10 以上，很多 Agent 框架和 MCP SDK 都要求较新的 Python。
• 包管理工具：pip、uv 或 conda，任选一种。
• 代码仓库管理：git，用来拉取项目代码和更新依赖。
• 网络环境：确保可以访问模型 API 服务、GitHub、包镜像，具体企业网络策略以本地为准。

3.2 模型服务

项目需要大模型做推理。不确定文档里写的是 OpenAI、Anthropic 还是国内模型，稳妥做法是准备一个兼容 OpenAI API 格式的模型服务地址和 Key。DeepSeek 等国内模型的 API 往往支持同样的 SDK 格式，把 base_url 和 api_key 换成自己的就行。

# 环境变量配置示例 export OPENAI_API_KEY="your_api_key_here" export OPENAI_BASE_URL="https://api.deepseek.com/v1" export MODEL_NAME="deepseek-chat"

注意，不要把你的 API Key 提交到 git 仓库里。建议放在.env文件，并加入.gitignore。

3.3 Python 虚拟环境

每个项目独立虚拟环境，避免依赖冲突。示例命令：

python -m venv .venv source .venv/bin/activate # Windows 上用 .venv\Scripts\activate pip install --upgrade pip

3.4 依赖安装

典型依赖包括 Agent 框架、MCP SDK、Web 框架等。先用通用命令安装：

pip install mcp pip install openai pip install langgraph # 如果项目使用 LangGraph 作为 Harness pip install fastapi uvicorn pip install python-dotenv

如果项目要求固定版本，直接使用项目提供的requirements.txt或pyproject.toml：

pip install -r requirements.txt

安装失败时优先检查 Python 版本是否匹配、网络是否畅通、包名是否完整。不要盲目升级所有包，可能引发更大的兼容性问题。

4. Multi Agent 协作架构设计

这一节是整个项目的核心。多智能体不是简单地把多个模型调用堆在一起，而是要设计一套“任务拆解 - 角色分工 - 结果汇合”的协作机制。

4.1 多 Agent 协作模式

项目标题里出现的 Multi Agent 和 Deep Agent，通常对应几种经典协作模式。

• 编排模式：一个 Supervisor Agent 负责拆解任务、派发给多个 Worker Agent，最后聚合结果。
• 流水线模式：Agent A 的输出作为 Agent B 的输入，适合有明确先后顺序的任务。
• 评审模式：一个 Agent 生成内容，另一个 Agent 负责审核修改，类似 Red Team。
• 递归/深度模式：Agent 在执行过程中发现子任务，动态创建子 Agent 完成后再继续。

AI 职业规划场景非常适合编排模式。可以拆成这样：

这样设计的好处是：每个 Agent 的 Prompt 只聚焦一个小任务，上下文更短、工具调用更精准、结果质量也更容易控制。

4.2 任务状态管理

多 Agent 协作必须考虑状态管理。每个子任务要有明确的执行状态：待执行、执行中、成功、失败、已重试。最简单的做法是定义一个 Python 数据类来保存状态。

from dataclasses import dataclass from typing import Any, Optional @dataclass class AgentTask: task_id: str agent_name: str status: str = "pending" # pending, running, success, failed input_data: Optional[dict] = None output_data: Optional[Any] = None error: Optional[str] = None retry_count: int = 0

在正式项目里可以用数据库表或 Redis 存储这些状态，方便断点续跑和故障恢复。第一次跑通时，直接用内存 dict 也可以，但至少要保证状态打印清晰，便于调试。

5. Harness 执行框架设计

Harness 是项目里最容易疑惑的概念。一句话解释：Harness 是“约束 Agent 行为、管理工具调用循环、控制上下文窗口、决定何时停止”的运行容器。如果说 Agent 是大脑，Harness 就是让大脑按流程工作的控制台。

5.1 Harness 要解决什么问题

没有 Harness 时，很多 Agent 代码是散落的：

# 伪代码，展示没有 Harness 时的问题 response = llm.chat(user_input) if "search" in response: tool_result = search(response["query"]) response2 = llm.chat(response + tool_result) if "database" in response2: ...

这种写法最大的问题是逻辑不可控。模型什么时候调用工具、调用多少次、调用后结果如何回传，全部埋在代码里，项目一复杂就失控。Harness 把这些逻辑抽象成统一执行循环，让每个 Agent 都以相同方式运行。

5.2 核心循环逻辑

一个典型的 Harness 执行循环包括：

1. 接收输入和可用工具列表。
2. 判断是否结束：如果模型输出已包含最终答案，停止。
3. 如果模型请求调用工具，执行工具函数。
4. 把工具结果返回给模型。
5. 重复，直到达到最大迭代次数或 Token 上限。

下面是通用 Python 伪代码，展示 Harness 的循环骨架：

from typing import Callable, List class ToolSpec: def __init__(self, name: str, description: str, handler: Callable): self.name = name self.description = description self.handler = handler class Harness: def __init__(self, llm, tools, max_iterations=5): self.llm = llm self.tools = {t.name: t for t in tools} self.max_iterations = max_iterations def _call_tool(self, name: str, args: dict): if name not in self.tools: return {"error": f"Unknown tool: {name}"} try: return self.tools[name].handler(**args) except Exception as e: return {"error": str(e)} def run(self, prompt: str, context: str = "") -> str: messages = [{"role": "system", "content": context}, {"role": "user", "content": prompt}] for _ in range(self.max_iterations): response = self.llm.chat(messages=messages, tools=[tool_schema(t) for t in self.tools.values()]) message = response["message"] # 如果模型返回工具调用 if message.get("tool_calls"): tool_calls = message["tool_calls"] messages.append(message) for tc in tool_calls: tool_result = self._call_tool(tc["function"]["name"], tc["function"]["arguments"]) messages.append({ "role": "tool", "tool_call_id": tc["id"], "content": str(tool_result) }) else: # 模型返回最终答案 return message["content"] return "Max iterations reached."

这个示例省略了 tool_schema 转换细节，实际项目中每个 Tool 都需要生成符合模型要求的 JSON Schema。这个循环的优点是通用，无论是行业研究 Agent、岗位分析 Agent，还是主控 Agent，都可以复用同一个 Harness。

5.3 上下文窗口控制

多 Agent 协作时 Token 消耗很快，Harness 必须控制上下文。常见做法有：

• 滑动窗口：只保留最近 N 轮对话。
• 摘要压缩：当上下文超长时，用 LLM 把历史总结成摘要再继续。
• 工具结果裁剪：工具返回过长时，截断或只保留关键字段。
• 子 Agent 隔离上下文：每个子 Agent 只看到自己的输入输出，不共享完整上下文字段。

6. Tools 工具注册与调用

Tools 是 Agent 连接外部世界的方式。没有 Tools，Agent 只能凭训练知识回答问题，无法获取实时数据，也无法操作外部系统。项目里，Tools 要解决的核心问题是统一注册、统一 schema、统一调用。

6.1 工具注册表

建议所有工具都集中注册，而不是散落在各个 Agent 文件里。示例：

import json def search_web(query: str) -> str: # 实际调用搜索 API，这里只做占位 return json.dumps({"query": query, "result": "search placeholder"}) def read_local_document(path: str) -> str: # 实际读取本地文档，注意路径安全问题 with open(path, "r", encoding="utf-8") as f: return f.read()[:2000] def query_database(sql: str) -> str: # 实际连接数据库执行查询 return json.dumps({"sql": sql, "rows": []}) def register_tools(registry): registry.register( ToolSpec( name="search_web", description="Search the web and return top results.", handler=search_web ) ) registry.register( ToolSpec( name="read_local_document", description="Read a local document, return the first 2000 characters.", handler=read_local_document ) ) registry.register( ToolSpec( name="query_database", description="Run a SQL query against the internal database.", handler=query_database ) )

工具函数有几个工程要点：

• 参数要能完整映射为 JSON Schema，模型才好理解该传什么值。
• 返回值要控制长度，避免撑爆上下文。
• 异常处理必须放在工具内部，不要让整个 Agent 循环崩掉。
• 涉及写操作的工具要加确认机制，防止 Agent 误操作。

6.2 工具调用安全

Agent 调用工具比人调用 API 更危险，因为模型可能产生幻觉参数。安全措施至少包括：

• 白名单：工具列表只暴露当前任务允许调用的方法。
• 参数校验：所有参数在工具内部校验类型、范围和合法值。
• 敏感操作二次确认：删除、写入、转账等操作要人工确认。
• 运行沙箱：涉及代码执行时，放到隔离环境。

7. MCP 服务接入实践

MCP 是 Model Context Protocol 的缩写，由 Anthropic 提出，目的是让 AI 应用通过统一协议调用外部数据源和工具。你可以把它理解成“AI 工具接口的标准化协议层”。

7.1 MCP 解决什么问题

没有 MCP 之前，每个 Agent 集成一个新工具都要重新写一遍接口逻辑。MCP 的思路是：

• 工具方实现一个 MCP Server，暴露自己的资源、工具、Prompt。
• Agent 侧通过 MCP Client 连接，使用统一协议消费这些能力。
• 同一个 MCP Server 可以被不同 Agent 框架复用，同一个 Agent 也可以连接多个 MCP Server。

这就像给 Agent 世界做了一个标准 USB-C 接口，接入新设备不用再换线。

7.2 一个最小的 MCP Server 示例

如果项目需要自己写 MCP Server，代码结构大体是这样：

from mcp.server.fastmcp import FastMCP mcp = FastMCP("career-agent-tools") @mcp.tool() def get_job_level_info(job_name: str) -> dict: """ 获取目标岗位的级别信息。 """ # 这里替换为真实的数据查询逻辑 return { "job_name": job_name, "levels": ["初级", "中级", "高级", "专家"], "annual_salary_range": "15-60万（视行业和城市而定）" } @mcp.tool() def analyze_skill_gap(target_skills: list[str], current_skills: list[str]) -> dict: """ 基于目标技能和现有技能，计算差距。 """ target_set = set(target_skills) current_set = set(current_skills) missing = list(target_set - current_set) return { "missing_skills": missing, "matched_skills": list(target_set & current_set) } if __name__ == "__main__": mcp.run(transport="stdio")

启动一个 MCP Server 没有固定的命令，取决于使用的 SDK。用 FastMCP 时一般是：

python mcp_server.py

如果项目需要把 MCP Server 作为 HTTP/SSE 服务运行，可能需要指定端口：

python mcp_server.py --transport sse --port 8899

具体启动方式和参数要看使用的 MCP SDK 版本，不要照抄。

7.3 MCP Client 接入

在 Agent 的 Harness 里，MCP Client 负责发现 Server 提供的工具列表，并在工具调用时转发请求。底层连接方式通常是 stdio 或 HTTP，Agent 代码一般围绕“工具发现 + 工具调用”两个接口封装。

# 伪代码，MCP Client 接入 Harness async def load_mcp_tools(server_url: str): client = await MCPClient.connect(server_url) tools = await client.list_tools() wrapped = [] for t in tools: wrapped.append(ToolSpec( name=t.name, description=t.description, handler=lambda **kwargs: client.call_tool(t.name, kwargs) )) return wrapped

重点要理解：MCP 改变了工具接入的方式，但没有改变 Harness 的整体职责。Agent 仍然需要决定“什么时候调用某个工具、如何解释调用结果”，只是工具本身变成了标准协议下的可发现服务。

8. Skills 技能机制实现

Skills 是近年来 Agent 工程里非常火的概念。它把“提示词 + 工具使用方式 + 处理逻辑”打包成一个可复用的单元，让 Agent 在遇到同类任务时直接加载，而不是临时推理。

8.1 Skills 的定位

Skills 和 Tools、MCP 有区别：

• Tools 是单个可执行函数。
• MCP 是工具的标准接入协议。
• Skills 是更高层的能力封装：一个 Skill 可能包含多个工具调用顺序、特定的提示词模板、以及结果校验规则。

例如“岗位能力分析”这个技能，内部可能包含：

1. 读取用户输入的岗位名称。
2. 调用搜索工具获取真实招聘信息。
3. 调用数据库工具查询历史薪资数据。
4. 用固定提示词模板让 LLM 生成能力矩阵。
5. 校验输出是否包含岗位、技能、薪资、发展路径等字段。

这些步骤被封装后，Agent 只要识别出“用户想了解岗位能力”，就直接触发该 Skill，避免每次都从头推理。

8.2 Skills 目录结构

在实现层面，Skills 常见结构是目录加上元信息文件：

skills/ skill_registry.json # 技能注册表，记录技能名称、描述、路径 job_analysis/ SKILL.md # 技能说明，包含触发条件和使用步骤 prompt_templates/ analysis_template.txt # 使用的提示词模板 scripts/ parse_job_info.py # 技能内部的脚本

SKILL.md里通常写明技能用途、依赖工具、执行流程和输出格式。Agent 框架运行时扫描技能目录，把可用技能信息注入系统 Prompt，让 Agent 知道什么情况下该调用什么技能。

# Job Analysis Skill ## Description 分析目标岗位的职责、技能要求、薪资区间和发展路径。 ## Trigger Conditions - 用户输入中包含岗位名称 - 用户询问职业发展路径 ## Workflow 1. 提取岗位名称 2. 调用 search_web 工具获取岗位相关信息 3. 调用 analyze_skill_gap 工具计算技能差距 4. 使用 analysis_template.txt 生成结构化报告 ## Output Format { "job_name": "", "responsibilities": [], "required_skills": [], "salary_range": "", "career_path": [] }

8.3 Skills 与 Deep Agent 的关系

Deep Agent 强调的是“深度拆解和递归执行”，Skills 其实是深度执行的基础。一个 Deep Agent 在遇到复杂任务时，把任务拆成多个子任务，每个子任务对应一个 Skill 或子 Agent。比如做完整职业规划时：

1. 主控 Agent 识别这是一个“职业规划综合任务”。
2. 动态加载行业研究 Skill、岗位分析 Skill、能力评估 Skill。
3. 将不同 Skill 分发给对应 Worker Agent。
4. Worker Agent 执行后返回结构化结果。
5. 主控 Agent 汇总生成最终报告。

这里，“深度”体现在 Agent 不满足于一次回答，而是层层推进、不断调用更具体的能力单元。

9. 功能测试与效果验证

搭好架构后，不能只看代码能运行，还要验证多 Agent 协作是否真的“协作”起来。下面给出一套通用验证流程，适合没有官方测试脚本的项目。

9.1 最小链路验证

先不要跑完整职业规划流程，用小任务验证每个模块是否正常。

9.2 AI 职业规划完整测试用例

作为演示场景，完整测试需要准备一份用户输入：

用户背景：3 年前端开发经验，熟悉 Vue/React，目前想转行做 AI 产品经理， 希望了解需要补哪些技能，以及未来三年怎么安排。

预期流程：

1. 主控 Agent 识别“转行规划”需求。
2. 行业研究 Agent 给出 AI 行业当前热门方向。
3. 岗位分析 Agent 输出 AI 产品经理能力矩阵。
4. 能力评估 Agent 对比用户技能，得出差距。
5. 路径规划 Agent 根据差距生成学习路线。
6. 审核 Agent 检查报告，输出终版。

判断是否成功的标准：

• 各 Agent 都被正确触发，没有出现“主控 Agent 自己做完全部任务”的情况。
• 工具调用次数和类型符合预期。
• 最终报告包含行业分析、岗位要求、差距分析、学习计划四个部分。
• 完整链路在可接受的 Token 预算和时间范围内完成。

9.3 稳定性测试

多 Agent 系统最常见的失败是链路中途挂起。建议做以下稳定性测试：

• 连续运行 10 次完整职业规划任务，记录成功率。
• 设置模型返回异常格式，观察 Harness 是否能把错误回传并继续。
• 让工具返回超长内容，观察上下文是否溢出。
• 突然断开网络，观察是否有超时和重试机制。

10. 接口 API 与批量任务

多 Agent 框架如果不提供接口服务，只适合本地离线调试；一旦要接业务，就需要把完整流程包装成 API 服务。

10.1 接口服务设计

一个常见的做法是封装一个 FastAPI 服务，把“用户输入”映射到“多 Agent 协作任务”。

from fastapi import FastAPI from pydantic import BaseModel app = FastAPI() class CareerPlanRequest(BaseModel): user_id: str background: str target_role: str extra_notes: str = "" class CareerPlanResponse(BaseModel): task_id: str status: str report: dict = {} error: str | None = None @app.post("/api/v1/career-plan", response_model=CareerPlanResponse) async def create_career_plan(req: CareerPlanRequest): task_id = create_task(req) return CareerPlanResponse(task_id=task_id, status="submitted")

启动服务：

uvicorn api_server:app --host 0.0.0.0 --port 8000

注意：接口服务要加鉴权，避免被任意调用刷 Token。没有材料说项目是否自带鉴权，稳妥做法是自己在 Gateway 层加 API Key 或 OAuth。

10.2 Python 调用示例

import requests url = "http://127.0.0.1:8000/api/v1/career-plan" payload = { "user_id": "u_123456", "background": "3年前端经验，熟悉Vue/React", "target_role": "AI产品经理", "extra_notes": "偏向B端产品方向" } response = requests.post(url, json=payload, timeout=60) print(response.json())

如果接口是“提交后异步返回”，需要通过 task_id 轮询或 WebSocket 获取结果。异步方案对长任务更友好，避免 HTTP 超时。

10.3 批量任务设计

批量任务要解决的是吞吐一致性问题。假设有 100 个用户需要生成职业规划报告，不能一次性并发 100 个 Agent 任务，需要队列控制并发。

import queue import threading task_queue = queue.Queue(maxsize=4) result_store = {} def worker(): while True: task = task_queue.get() if task is None: break try: result = run_career_plan(task) result_store[task["task_id"]] = {"status": "success", "result": result} except Exception as e: result_store[task["task_id"]] = {"status": "failed", "error": str(e)} finally: task_queue.task_done() def submit_batch(tasks): for t in tasks: task_queue.put(t) return [f"task_{idx}" for idx in range(len(tasks))]

批量任务的工程要点：

• 并发数要压测后再定，避免打爆模型 API。
• 每个任务要有唯一 task_id，方便追踪失败项。
• 失败任务要有重试逻辑，重试次数建议不要超过 3 次。
• 结果要落盘或入库，不能只存在内存里。

11. 资源占用与性能观察

多 Agent 系统的资源占用主要分两块：框架本身的 CPU/Memory 开销，以及模型调用的 Token/API 费用。显存不是主要瓶颈，除非你本地运行小模型。

11.1 观察方法

• 启动 Agent 框架后，用htop或任务管理器看内存占用。
• 观察模型 API 调用日志，统计每次任务的 Token 消耗。
• 用time命令统计完整任务耗时。
• 检查 Harness 是否因为循环次数过高导致响应缓慢。

11.2 性能影响因素

11.3 降低成本的手段

• 大部分子任务用中等大小的模型，只有主控 Agent 或审核 Agent 用更强的模型。
• 工具结果尽量结构化，减少模型二次整理的比例。
• 缓存相同岗位的分析结果，同一岗位只跑一次全链路。

12. 常见问题与排查方法

多 Agent 项目调试比普通应用复杂，问题往往出现在“看起来都正常，但结果不对”的情况。下面整理一份排查清单。

如果是“Agent 执行中突然终止”（对应 Agent execution terminated due to error 一类报错），优先检查两点：一是 Harness 的异常捕获是否完整，二是工具调用过程中是否有未捕获异常。不要只盯着模型输出，先看日志里最后一条工具调用是什么。

13. 最佳实践与使用建议

最后给出一套可以直接用于实际项目的工程化建议。

13.1 从最小闭环开始

不要一开始就搭建 6 个 Agent 的完整系统。先做两步：

• 单个 Agent + 单个 Tool：跑通工具调用闭环。
• 两个 Agent + 汇总逻辑：验证多 Agent 协作基本模型。

再逐步增加 Skills、MCP Server 和批量任务。每一步都保留一个可运行版本，便于回滚。

13.2 把配置外置

Agent 数量、模型名称、工具开关、最大迭代次数都应该是配置项，不要写死在代码中。用.env或 YAML/JSON 配置：

agents: supervisor: model: deepseek-chat max_iterations: 5 career_analysis: model: deepseek-chat max_iterations: 3 tools: search_web: enabled: true query_database: enabled: false mcp_servers: career_tools: transport: sse url: http://127.0.0.1:8899 skills: scan_path: ./skills

13.3 日志是关键

多 Agent 系统最重要的工程投入是日志。每个 Agent 的开始、结束、工具调用、Token 消耗、错误细节都要有日志。推荐结构化 JSON 日志，方便后续用日志平台检索分析。

{ "timestamp": "2025-06-01T10:00:00Z", "event": "tool_call", "agent": "job_analyzer", "tool_name": "search_web", "status": "success", "latency_ms": 3120 }

13.4 合规与安全底线

• 模型 API 输出要人工抽检，避免生成含有偏见或错误职业建议。
• 涉及个人隐私信息时，做到最小化收集，使用后及时删除。
• 工具调用要有访问控制，特别是写文件和删除操作。
• 商用前确认模型服务条款允许预期使用方式。
• 涉及版权素材、人脸照片、声音样本时，必须确认授权。

14. 总结与下一步

这个项目最值得尝试的点，不是某个单独功能，而是把 Multi Agent、Harness、Tools、MCP、Skills 这些容易停留在概念层面的词，落成一个可以运行和验证的工程模板。最先应该验证的功能是“一个主控 Agent 调度两个 Worker Agent 并汇总报告”，这是整个体系的地基。最容易踩的坑是让主控 Agent 大包大揽，结果多 Agent 形同虚设；解决方案就是把任务拆解逻辑写清楚，让子 Agent 有明确边界。

后续可以继续扩展的方向：接入真实数据库和搜索服务，把 MCP Server 从 stub 换成正式实现；把 Skills 做得更厚重，每个 Skill 自带评估与回测；增加人工反馈机制，用真实用户评价优化每个 Agent 的 Prompt；还可以把批量任务从职业规划扩展到更多垂直领域，比如简历优化、面试模拟、学习路径生成。

如果你正在规划自己的 Agent 项目，可以先以这套体系做技术对标。先不用管模型多强，先把 Harness 循环跑通，再让 Agent 学会调用工具，然后逐步接入 MCP 和 Skills。等这套骨架稳定了，再决定换什么模型、接什么服务，都只是配置层面的事情。建议先把这篇收藏备用，需要搭多 Agent 项目时拿出来对照着改。