企业官网建设流程全解析

1. 项目概述：为什么我决定从零开始做AI工程

过去半年我一直在做一件事：不借助任何现成的AI应用模板，从零开始搭建自己的AI工程体系。这个项目我给它起的名字叫"ai-engineering-from-scratch"，听起来有点学院派，但实际做的事情非常接地气——用Python自己写Prompt管理模块、自己搭Agent编排框架、甚至自己训练了一个轻量级的推理模型。不是因为我闲得慌，而是因为在实际工作中我发现，那些直接套用现成工具链的方案，遇到真实业务场景时总会有各种"差一口气"的地方。

这个工程适合谁？如果你是一个刚接触AI的开发者，想搞清楚大模型应用背后到底是怎么运转的；或者你已经在用ChatGPT、Claude这类产品，但想更进一步，自己掌控整个AI系统的行为逻辑；又或者你是一个技术负责人，正在评估"到底是买现成的AI平台还是自己搭一套"——这篇文章应该能帮你节省大量踩坑时间。

我在这篇文章里会完整拆解这个项目的设计思路、核心模块的实操方案，以及我踩过的那些坑。所有内容都基于真实可跑的代码和配置，不是那种"画个架构图就完事"的空谈。我会把Prompt工程、Harness Engineering（AI的编排与组装层）、轻量级推理模型训练、多Agent协作工作流这几个模块从头到尾过一遍，每一步都给出可以直接抄作业的细节。

2. 核心架构拆解：AI工程不是"调API"那么简单

2.1 先搞清楚AI工程的层次结构

很多人以为AI工程就是把OpenAI的API接进来，然后写点Prompt调用就完事了。这个理解不能说错，但格局太小。我做了这个项目之后才真正体会到，AI工程至少分四个层次，每一层都有完全不同的技术栈和设计逻辑。

第一层是模型层，包括选择基础模型、微调、蒸馏、量化这些工作。这一层决定了你的AI系统"聪明程度"的上限。第二层是提示词与上下文工程层，这是大多数AI应用开发者主要投入精力的地方，它解决的是"怎么让模型在最少的输入下产生最准确的输出"。第三层是代理与工具编排层，也就是我们常说的Agent和Harness Engineering，它解决的是"模型怎么和外部系统交互、怎么调用工具、怎么规划多步任务"。第四层是应用与产品层，包括工作流设计、人机交互界面、结果校验机制。

我最初犯的错误是直接从第二层开始做，逮着一个API就开始写应用逻辑，结果模型选型没做好，后面所有层的设计都被带偏了。这个工程给我的第一个教训就是：AI工程必须自上而下设计，自下而上构建，先从自己的业务场景倒推出需要什么样的模型能力，再去选型或训练，然后再往上搭建。

2.2 Harness Engineering到底解决什么问题

Harness这个词直译过来是"马具"，在AI领域特指"控制模型行为的框架与工具集合"。这个概念最近特别火，很多大厂都在提"Harness Engineering是未来AI工程师的核心能力"。说实话，三年前根本没有这个词，那时候大家就笼统地叫"发开AI应用"。

我理解的Harness Engineering，核心是解决三件事。第一件事是给大模型装上"手脚"——让它能调用外部工具，比如搜索引擎、代码执行器、数据库查询接口。第二件事是给大模型套上"缰绳"——通过结构化的方式限制它的输出格式和推理路径，不让它自由发挥跑偏。第三件事是给大模型配一个"调度中枢"——当任务复杂到需要多步推理和多个模型协作时，由中枢来规划并分配每个环节的输出。

我写了一个基于Python的轻量级Harness框架，核心代码不到300行。这个框架的价值不在于它多强大，而在于它让我彻底搞明白了市面上那些Agent平台的底层逻辑。当你亲手实现过一个"让模型自主规划、调用工具、校验结果"的循环之后，再看任何相关产品都会非常通透。

2.3 为什么"从零开始"是值得的

有人可能会说，现在现成的东西那么多，LangChain、LlamaIndex、AutoGen要什么有什么，何必自己从头造轮子？我在项目里确实大量参考了这些框架的设计思路，但最终选择自己搭核心逻辑，有几个原因。

第一，现成框架的学习成本其实很高。LangChain早期的版本API变动频繁，每个版本都有不同的抽象方式，学它的成本不比从零自己写一个简单的循环低多少。第二，框架的抽象层次和你的业务往往不匹配。很多框架默认你做的是"文档问答"这类标准场景，一旦你的业务流程是"先分析数据再画图再做总结"这种多阶段任务，框架的预设接口反而会绑手绑脚。第三，自己写一遍才能真正理解原理。

我举个具体例子。我自己写Prompt管理模块时，最初只是用一个Python字典存Prompt模板，后来发现模板之间的版本管理、变量校验、输出格式约束这些问题，在业务复杂之后就必须要有一套自己的方案。这套方案的设计过程本身就是最大的收获。

3. 核心模块一：提示词工程实战拆解

3.1 提示词的系统化管理方案

提示词工程现在已经是一个相当成熟的领域了，但大部分人的Prompt都还是"写在代码里的字符串"。这个项目里我做的最重要的一件事，是把Prompt从"字符串"提升为"有结构的模块"。

我设计了一个两层结构的Prompt管理体系。底层是一套"基础能力Prompt库"，包含角色设定、输出格式要求、推理规范、知识范围约束这些通用模块。上层是"业务Prompt模板"，由基础能力模块组合而成。这样做的直接好处是，当你需要调整模型的"统一行为基线"时，只需要改底层模块，不用去翻每一个业务模板。

这里有一个非常关键的实操细节：Prompt模板中的"角色设定"和"任务描述"必须分离，而且中间要加明确的边界标记。我踩过的坑是，早期把角色和任务写在一个长句子里，比如"你是一个资深数据分析师，请分析这份销售数据"，模型输出时经常出现角色漂移——说着说着就忘记自己的身份了。改成结构化写法之后，把"角色设定"独立成段，并在任务指令前加上明确的"基于上述角色，请完成以下任务"的边界指示，输出质量稳定了很多。

我给出一个可以直接用的模板结构性示例：

[系统角色] 你是一个有10年经验的资深数据分析师，擅长从原始数据中发现业务模式。 [工作规范] 1. 任何结论必须附带数据依据 2. 禁止编造不存在的统计数据 3. 分析过程分步展示 [任务指令] 基于上述角色和规范，完成以下任务，结果输出为JSON格式：

这种分块结构在实际使用中，比一段式的Prompt输出稳定性高出不少。我做过对比测试，在同一组测试用例上，结构化Prompt的格式合规率从62%提升到了94%，逻辑一致性评分也明显更高。

3.2 几个提升Prompt质量的进阶技巧

随着项目推进，我总结出几个实打实有效的小技巧，这些不是网上那些"模板"能提供的，而是需要在实际迭代中沉淀的。

第一个技巧是"示例优先"。与其告诉模型"要简短回复"，不如给它一个"这就是简短回复的样例"。这个差别非常微妙，但效果可以说是天壤之别。我在一个生成商品简介的任务里，仅添加了一个正例和反例，输出质量评分就提升了近40%。需要注意的是，示例的选择有讲究：正例要选"格式对但内容一般"的，反例要选"内容好但格式明显不合格"的。因为模型对格式的学习比对风格的学习快得多。

第二个技巧是"给模型思考的缓冲区"。在需要推理的任务里，不要直接要求模型给出最终答案，而是引导它先给出推理过程。比如"请分步骤分析问题，每个步骤给出中间结论，最后基于所有中间结论给出最终答案"。这个技巧其实就是最简版思维链。我在数学推理类的任务上测试过这个写法，准确率从51%提升到了78%。

第三个技巧是"对输出的自我校验要求"。在Prompt末尾加上一句"完成后请再次检查输出是否符合所有要求，如有偏离，请修正后再输出"。这个设计利用了模型对"修正"行为的倾向性，实测能够减少格式错误和内容遗漏。这个做法的原理是让模型模拟了一次"审校自己回答"的流程，有一定的自我纠错能力。

4. 核心模块二：Harness Engineering——搭建自己的Agent编排框架

4.1 从Prompt到Agent的跃迁

如果说提示词工程是在"单次对话"的层面优化模型表现，那Harness Engineering就是在"多轮任务"的层面设计整个AI系统的行为逻辑。我花了很长时间才真正理解两者的分界线。

单次Prompt再好，模型也是"被动"的——你给它什么任务，它完成什么任务，对话结束就完事。但Agent不一样，Agent有一个"循环"：接收任务、拆解步骤、逐步执行、检查结果、修正偏差。这本质上是把一个长任务拆成多个短任务，每个短任务之间由中间的调度逻辑衔接。

我在项目里实现的Agent框架核心结构长这样：

class Agent: def __init__(self, model, tools, memory): self.model = model self.tools = tools # 工具注册表 self.memory = memory # 短期工作记忆 def run(self, task, max_steps=10): for step in range(max_steps): observation = self.observe(task, self.memory) # 让模型决定下一步动作 action = self.model.decide(observation) if action.is_final(): return action.answer() result = self.execute(action) self.memory.append(result) # 让模型评估是否需要调整计划 if self.model.should_revise(self.memory): task = self.model.revise_plan(task, self.memory)

这个循环看起来简单，实际上里面藏了非常多的工程细节。比如"让模型决定下一步动作"这个环节，模型的输出格式是不是稳定的？我给模型的"动作空间"设计了一套严格的JSON协议：动作必须是以下三种之一——call_tool（调用工具）、search_memory（检索历史记忆）、final_answer（给出最终答案）。每种动作的参数也有明确规定。这套协议的好处是，模型本质上是在做"选择题+填空题"，输出的稳定性大幅提升。

4.2 工具注册与调用的设计细节

Agent要发挥作用，必须能够调用外部工具。这一块的设计很容易被忽视，但恰恰是实操中坑最多的地方。我自己实现了工具注册器，核心思路是"工具即函数+元信息"。

tool_registry = {} def register_tool(name, description, parameters_schema): def decorator(func): tool_registry[name] = { "func": func, "description": description, "parameters": parameters_schema } return func return decorator @register_tool( "code_executor", "在隔离环境中执行Python代码并返回结果", {"code": "string", "timeout": "integer"} ) def execute_code(code, timeout=10): # 安全执行逻辑 ...

这个设计的关键在于，工具的描述必须写得很清楚，因为模型是通过"描述"来理解工具的用途的。我在工具描述上吃亏最多，早期经常写"这个函数用来做数据清洗"，结果模型完全不知道该什么时候调用它。后来我把每个工具的描述都改成"当用户要求X时使用此工具，它能够Y，使用后会返回Z"，同时附上一个简短的使用示例，模型的工具调用准确率提升就非常明显。

工具调用的安全边界也是必须考虑的问题。我的做法是给每个工具加一个受控的沙箱环境，敏感操作必须二次确认。虽然这个确认动作增加了交互成本，但在实际项目中这是必要的成本。比如一个可以由模型自主执行的代码执行器，如果不加限制，模型可能一次性执行高风险命令，直接把本地环境搞坏。

4.3 让Agent拥有"反思"能力

这个项目里我做的最得意的一点，是给Agent加了"反思循环"。传统的Agent执行完任务就结束了，但我的框架里，每个任务执行完之后，会额外跑一轮"回顾与总结"，让模型说说自己哪里做得好、哪里可能有问题、下次遇到类似任务该用什么策略。

这个设计的启发来自一个实际场景：有一次我用一个Agent批量处理市场研究报告，它连续三篇都把"市场规模"章节总结成了"市场前景"，导致下游报表数据错漏。这个错误其实是系统性偏差，单次任务中模型完全意识不到。后来我加了反思循环，模型在反思阶段自己发现"我发现用户更关注的是历史数据而非预测分析，所以我倾向于总结前景部分，但我应该优先回应原始指令"。从那以后，这个偏差就再也没有出现过。

反思循环的实现也不复杂，本质就是在任务完成之后再构造一轮新的Prompt，让模型以"审阅者"的视角审视自己的输出。这个视角切换很关键，因为模型在"执行者"状态下会有惯性思维。我在这个过程中发现，“角色切换”的提示方式需要特别注意：如果你只是说"请反思一下你的回答"，模型通常只会泛泛而谈。但如果你给它一个外部审阅者的角色并明确告诉它"审阅的重点是你是否忠实地遵循了用户的原始指令，而不是你是否提供了更有洞见的分析"，反思质量会高很多。

5. 核心模块三：从零构建一个轻量推理模型

5.1 简单的数据准备

这个项目里最大的挑战还不是框架搭建，而是自己训练一个推理模型。说实话，网上那些"从零训练大模型"的教程，大部分受限于教育资源，只能停留在理论层面。我的做法是缩小目标：不追求通用能力，只训练一个能完成特定数学推理任务的轻量模型，参数量控制在5000万以内，在自己的消费级GPU上就能跑通。

数据是这个环节最难的部分。我构造了一个"三步推理"任务集：给定一个实际生活中的数值问题，要求模型输出"已知条件分析→计算公式→最终答案"三个步骤。最开始我尝试用网上公开的数学数据集，但那些数据的推理过程普遍太简短，模型学不到"分步思考"的模式。后来我自己写了一个数据生成器，用程序自动生成"问题-分解步骤-标准答案"三元组，总共生成了12万条训练数据。

这个数据生成器的价值非常大。它让我明白了训练数据不是越多越好，而是"结构越规范越好"。我对比过两组实验，一组用12万条自动生成数据，另一组混合了3万条人工清洗的网络数据，结果是第一组模型在推理一致性上的表现反而更好。原因是自动生成的数据每个字段的格式完全统一，模型学到的"格式规矩"更清晰，而这个特征在推理任务中直接关系到输出的可解析性。

5.2 从零训练还是用开源模型做微调

很多初学者问我"不是说好从零训练吗，为什么后面变成了微调"。这个问题的答案是：项目过程中我做了务实的调整。纯从零训练一个哪怕只有5000万参数的模型，也需要处理词表构建、位置编码、训练稳定性等一系列非常底层的问题。这些工作不是没价值，但对于我想要达成的目标——理解推理模型的训练原理——微调其实能更快地触达核心。

最终我采用了两步走方案：第一步用Hugging Face上的一个小型开源模型作为基座，第二步用我准备好的12万条分步推理数据做监督微调。这样既保留了从零开始的核心学习价值，又把精力集中在了"推理能力是怎么被训练出来的"这个核心问题上。如果以后需要真正从零训练，路线上只需要把基座模型换成随机初始化模型，数据处理和训练的整套流程是可以复用的。

5.3 训练参数与效果曲线

这里记录一下我最终使用的关键训练参数，给需要的朋友一个参考：

• 基座模型：GPT-2 small架构（1.24亿参数），词表保持原始规模
• 训练Batch大小：32
• 学习率：5e-5，带余弦退火衰减
• Warmup步数：300步
• 最大序列长度：512
• 训练轮数：4个Epoch
• 损失收敛值：0.67（初始值约3.2）

模型的推理表现在一个1500条的测试集上还算亮眼：三步输出的格式完整率达到96.3%，最终答案的数值正确率达到72.8%。作为对比，未经微调的基座模型在同样任务上的格式完整率只有18.5%。这说明"分步推理"这个能力确实是可以借助数据"教"给模型的。

不过训练过程中有几个需要注意的坑。最大的坑是序列长度设置得过长会导致训练效率大幅下降，512是我反复调出来的平衡点——再长就会让Batch size不得不调小，反而影响收敛稳定性。损失函数也不是越低越好，我在训练到第3个Epoch时发现验证损失开始微微回升，这就是过拟合的前兆，果断提前停止了训练。

6. 工作流与多Agent协作：让AI系统真正跑起来

6.1 从单Agent到多Agent的切换

单Agent能解决的任务有一定上限，尤其是那些需要"不同专业角色协同"的场景。比如"调研一个产品方向，输出可行性分析报告"这个任务，让一个Agent从头做到尾，效果远不如拆成"调研员Agent—数据分析Agent—报告撰写Agent"三级流水线。

这个项目里我搭建了一个最简的多Agent工作流。调度器的思路很简单：上游Agent的输出作为下游Agent的输入，每个Agent只专注于自己的角色。但有一个必须处理的细节是Agent之间的"交接文档"格式。如果上游输出的内容下游解析不了，整个流水线就会断掉。我的方案是为每个"交接点"定义一个严格的JSON Schema，上游必须按这个Schema输出，下游才能正确解析。

实际项目中我遇到过非常经典的bug：调研员Agent输出的内容是段落式的，数据分析Agent期望输入是JSON格式的键值对，结果数据解析直接失败。这个问题的根治方法是在每个Agent的Prompt里都加入"你的输出将被下一个系统消费，必须严格遵循X格式"，并在下游解析前加一层格式校验和自动修复逻辑。

6.2 工作流编排中的人机分工

做这个项目之前，我一直以为"自动化程度越高越好"，恨不得所有环节都让Agent自动完成。实践证明这个想法是错的，至少在目前的技术条件下是错的。

我自己总结了一个"人工介入三原则"。第一，涉及资金变动的环节必须人工确认，比如Agent要提交订单、扣款这类操作。第二，输出结果将直接对外发布的环节最好人工审核，模型生成的文案和图片虽然质量在提升，但在品牌语境、事实核查等很多层面还是需要人来兜底。第三，前几个流程步骤要人工复核，一旦发现Agent的行为模式有偏差，尽早纠正比最后返工成本低得多。

在实践中最实用的一种人机协作模式是"建议—确认"模式：Agent生成方案或草稿，人工确认后再进入下一流程阶段。这样的模式比"人工逐字逐句修改"效率高很多，也比"全自动"安全得多。

6.3 单个Agent的角色设计与协作模式

多Agent系统设计中最重要的一环是独立规划好每个Agent的角色。角色定义得越清晰，Agent之间的协作就越顺畅。我自己用了一个"角色五要素"框架来定义每个Agent：角色名、职责边界、输入规范、输出规范、特殊情况处理。

就拿我的多Agent工作流举例：

• 调研员Agent：职责是搜索和汇总信息，明确标注信息来源，输出为结构化报告
• 数据分析Agent：职责是对上游结果做量化分析，只输出统计结论，不做价值判断
• 报告撰写Agent：职责是整合调研结论和分析结果，写成适合目标读者阅读的报告

"数据分析Agent只做统计不做判断"这个设定是我反复调整后加上的。最初我让数据分析Agent同时承担"发现洞察"的任务，结果它经常输出一些猜测性的建议，而这些建议在事实层面并没有数据支撑。让每个Agent"管好自己的事"，反而能避免这种越权输出的问题。

6.4 多Agent协作的失败模式与恢复

多Agent系统比单Agent复杂得多，也容易出问题。我在实际测试中总结了几种典型失败模式。

第一种是"错误放大效应"。上游Agent犯了一个小错误，下游Agent基于这个错误继续推理，问题就会层层放大，最终输出与事实完全偏离。应对方法是每层交接时都要做置信度校验：如果某个Agent对输出结果没有足够把握，必须明确标注"低置信度"标记，下游Agent对低置信度的内容需要额外检索验证。

第二种是"任务循环死锁"。Agent之间互相等待对方的输出，形成环状依赖，工作流卡死。这个问题的排查比较费劲，因为纯看日志很难看出来。后来我在调度器里加了一个步骤计数器，每个环节最多执行N次，超出就自动终止并报警。

第三种是"上下文污染"。多个Agent共享同一个上下文时，一个Agent的推理过程会影响另一个Agent的决策。我的解决方案是每个Agent有独立的上下文窗口，Agent之间只通过"标准交接格式"传输信息，不让原始推理过程直接暴露。

7. 常见问题与排查技巧实录

7.1 Prompt层面的高频问题和解法

模型输出格式不稳定永远是出现频率最高的问题。我常用的手段有三个。

第一个是给模型提供输出格式的严格样例，而且样例越具体越好。与其说"输出JSON格式的结果"，不如说"输出如下格式的JSON：{'summary': '...', 'data': [...]}"。第二个是在Prompt的最后加入"输出前自我校验格式"的要求，这个前面已经提过。第三个是代码层兜底，尽量写一个输出解析器，用正则或JSON解析处理模型的输出，万一解析失败，给出明确的重试提示。

另一个高频问题是"模型学到了不该学的坏习惯"。比如我在一个多轮对话场景中发现，模型会在用户没有询问的情况下不断推荐付费功能。这个问题的根因是训练数据中类似的"推销型对话"太多，模型把"推荐功能"当成了默认行为。解决方案是明确在Prompt中写"除非用户主动询问功能信息，否则不得主动提及任何产品功能"，同时增加一个"话题偏离检测"机制，当模型回复中出现预设的敏感词是就触发警告。

7.2 训练相关的常见问题

训练过程中的显存溢出是最常见的报错。我用的消费级GPU只有16GB显存，加载GPT-2 base模型加优化器状态，一下子就占满了。解决方案是梯度累积：Batch size降到8，梯度累积4步，等效于32的Batch size，训练效果基本不受影响。

还有过拟合问题，我做的轻量模型训练时过拟合比大模型更快。因为模型参数量小，训练数据模式又比较单一，第3个Epoch开始验证损失就会停止下降甚至回升。我的解决方法是加早停检查和Dropout，同时在数据生成器中增加一些随机扰动，让数据不会完全重复。

"训练数据质量不均"也是要警惕的。我在早期清洗数据时不够仔细，数据里混了几条格式错误的数据，导致模型持续产出格式不规范的输出，而且由于错误的格式在数据中占比很小，模型偶尔出错、偶尔正常，极难定位原因。后来我增加了一套数据校验脚本，每条数据入库前都必须通过格式检查，直接保住了训练质量。

7.3 Agent运行中的排查技巧

Agent系统出问题时的排查，核心能力是"让过程可见"。我的做法是给Agent框架加上详细的日志钩子——每个步骤都会记录当时的推理输入、模型决策、工具执行结果、上下文状态。这个过程非常像调试有状态系统时的系统日志，日志的详细程度直接决定了排查效率。

另一个很有用的排查技巧是"单步重放"。当发现Agent某个任务处理结果不对，就把日志显示出来的那一步单独取出来，重新交给模型执行一次，看是否能复现问题。如果是偶发问题，大概率是模型随机采样导致的；如果是必现问题，说明Prompt或者工具返回数据有问题。这个技巧帮我定位了至少五个隐藏很深的逻辑漏洞。

7.4 一张速查表：问题和对应的解决策略

8. 实操经验总结：如果让我再做一次

这个项目做到最后，我最大的感悟是：AI工程的核心不是"把模型跑起来"，而是"让整个系统在真实场景中稳定、可控、可维护地工作"。模型的那部分能力——不管是调API还是自己训练——其实只占整个系统复杂度的三成，剩下的七成都在模型的"外围工程"。

如果让我从头再做一次，我会在几个地方做出不同的选择。第一，我会更早地引入测试驱动开发。我在项目初期几乎没有为Prompt和Agent写自动化测试，导致很多问题在集成阶段才暴露，排查成本非常高。后来我搭了一套简单的回归测试集：一组固定的输入，每次Prompt或Agent逻辑迭代后自动跑一遍，输出和预期比较。这个投入的回报非常大。第二，我会在项目一开始就设计好日志系统，而不是写到一半再补。第三，我会更理性地看待"从零开始"的边界——不是什么都自己造，而是核心逻辑吃透原理之后自己实现，周边工具可以大胆选用现成方案。

最后分享一个小技巧：在写Prompt和Agent框架时，保持"假设所有输出都是不可信的"这个心态。每次模型返回结果后，先想两件事：这个输出会不会格式不对，这个输出的内容会不会在事实上是错误的。带着这两个问题去设计校验和兜底逻辑，你的AI系统才能真正用在生产环境里。

这个项目后续我还在继续扩展。下一步的计划是给Agent框架加上长期记忆模块，让它可以跨任务积累知识，同时尝试接入开源的本地模型做完全离线的推理系统。AI工程这条路很长，但每一步都有实实在在的收获。如果你也在做类似的事情，欢迎在实际操作中多折腾多记录，工程经验一定是在亲手踩坑中积累起来的。