企业官网建设流程全解析

两场活动放在一起看，很有意思：一场在北京亦庄，主题是AI产业的供需对接，企业带着算力、数据、落地场景而来；一场在杭州，主题是辩论，年轻人围绕AI技术的边界、方法和发展路径公开交锋。乍一看，前者务实，后者务虚，但36氪把它们放到同一个命题里，其实是在提醒我们一件事：AI行业已经过了“拼参数、比榜单”的叙事阶段，真正稀缺的是被明确定义出来的“真问题”——以及有能力把这些问题变成可交付工程的人。

这对开发者来说是一个重要的信号。过去两年，大家关注的是“模型有多强”，所以学习路径天然围绕模型API、提示词工程展开；而接下来，行业会转向“问题到底怎么解决”，技术重点会落到RAG、Agent、模型部署、评估调优、数据工程这些偏工程化的方向上。这篇博客不打算复述某一场活动的观点，而是想结合“AI真问题”这个命题，把其中对开发者最有用的部分拆开讲清楚：什么是AI的真问题，如何从产业需求中识别它，以及如何用AI工程化的方式把它落地成一个可运行的Agent应用。

1. 亦庄和杭州：AI的两个切面

1.1 亦庄对接会：产业已经在为“真问题”付钱

北京亦庄是国家级经济技术开发区，也是国内自动驾驶、智能制造、AI算力落地非常密集的区域。这类对接会最大的特点是没有“概念宣讲”，企业来是解决实际问题的：生产线上的次品检测能不能用视觉模型替代人工质检，仓储调度能不能用Agent自动协调订单与库存，客服积压的大量工单能不能通过大模型做分类和知识检索。

这些需求有一个共性：它们不是“能不能做出来”的技术挑战，而是“能不能稳定跑起来、成本能不能接受、出错怎么兜底”的工程挑战。企业愿意为这类问题付费，也说明AI的价值正在从“演示”转向“交付”。如果开发者还在用跑通一个Demo的标准来衡量自己的能力，那么对接会上绝大多数真实需求都是做不了的，因为它们涉及数据清洗、效果评测、异常处理、成本控制等一系列工程问题。

1.2 杭州辩论场：年轻人不再满足于“跑通demo”

杭州的辩论场是另一种画风。年轻开发者和学生在台上辩论的，往往不是“AI有没有用”这种结论，而是“ReAct模式比Plan-and-Execute更可靠吗”“RAG真的能解决幻觉吗”“Agent该不该拥有长期记忆”“工具调用应该由模型自主选择还是由业务规则限定”。这些问题的价值不在于辩论本身，而在于暴露了技术选型中大量没有被标准化的判断。

这说明AI应用开发已经进入深水区。跑通一个Agent demo并不难，难的是在限定预算、限定延迟、限定准确率的情况下，设计出适合业务场景的方案。很多在Demo阶段看起来“智能”的设计，一旦放到生产环境就会遇到上下文窗口不够、工具调用不稳定、日志不可追踪、反馈闭环缺失等问题。这一问题，恰恰是CSDN读者在真实开发中会高频碰到的。

1.3 为什么“真问题”是AI的分水岭

把这两场活动放在一起，会看到一个清晰的分界：产业侧在找能解决问题的方案，技术侧在找值得投入的方向，而能连接两者的，正是被准确表述的“真问题”。

什么是真问题？简单说，就是一类可以被验证、可以被定价、可以被工程化的问题。它不是“用AI做点什么”，而是“在某个具体场景里，用AI把某个业务指标从A提升到B，并且成本不超过C”。没有这个表述，AI项目很容易变成无底洞。开发者的核心竞争力，正在于把模糊的业务诉求转译成具体的技术方案——这一步需要模型知识，更需要工程思维。谁先学会定义真问题，谁就在接下来的AI工程化周期里占据主动。

2. AI的“真问题”到底是什么

2.1 从模型能力到工程交付

过去两年，业界的注意力集中在“基座模型的能力上限”上。大家默认一个逻辑：模型越强，应用越强。但在真实开发中，这个逻辑经常失效。一个70B的模型如果提示词设计得不好，可能不如一个7B模型加一个精心构造的检索链路效果好。这说明，模型能力只是AI应用的一个组件，而不是全部。

AI工程化的核心变化，是把重心从“模型训练与选型”转移到“系统交付与运维”。一个可用的AI应用通常由以下模块组成：模型服务、数据管道（包括检索、清洗、切片、入库）、编排引擎（也就是Agent逻辑）、工具调用层、评测反馈层、监控告警层。每一层都有大量工程决策，而模型只是其中一层。

对于CSDN读者来说，这其实是一个利好：它意味着即使你不做大模型训练，只要把RAG、Agent、模型部署、评测这些工程组件研究透，也能在AI应用中创造可量化的价值，而且这些能力比单纯调用API更有护城河。

2.2 AI Agent：问题工程化的天然载体

AI Agent（智能体）之所以成为热点，是因为它第一次让“问题解决”变成了一种可编程的流程。传统程序的逻辑是“输入-处理-输出”，开发者要把所有分支写清楚；而Agent的逻辑是“目标-拆解-工具调用-结果反馈”，开发者只需要定义目标、提供工具、设置边界，由模型在运行过程中动态规划路径。

这种变化有两个工程意义：

• 复杂问题的处理从“写死”变成了“编排”，系统的灵活性和可维护性同时提升。
• 问题解决的中间过程不再是不可观察的黑盒，而是可以通过日志、工具调用记录、中间结果存储来追踪。

但Agent也带来了新的“真问题”：模型可能规划错误，工具调用可能失败，上下文可能超限，成本可能失控。这些都不是模型能力本身的问题，而是系统设计必须回答的问题。也因此，Agent开发已经成了AI应用开发学习路线中不可绕开的一环。

2.3 AI应用开发学习路线的变化

AI应用开发学习路线正在发生变化。早期的学习路径是“Python基础 -> 机器学习概念 -> 深度学习 -> 大模型API调用”，这个路线本质上还是在训练模型。而现在的工程化路线更接近：

Prompt工程 -> RAG检索增强 -> Agent编排与工具调用 -> 模型部署与推理优化 -> 评估与反馈闭环 -> 生产级运维

这条路线有一个特点：每一步都在解决一类工程问题，而不是在追求一个更大的模型。这也是本文后面示例部分会刻意选择的路径——用一个最小Agent演示，帮助你把“AI真问题”落到可运行的代码上。

3. 从对接会需求到可执行方案：先做四步拆解

在实际项目里，很多AI应用失败，不是技术上做不到，而是在项目启动之初没有把“真问题”定义清楚。下面四步拆解方法，可以用于任何AI需求分析阶段。

3.1 识别问题类型

第一步，先搞清楚这个需求属于哪一类问题。常见的可落地方向包括：

• 信息压缩与生成：总结、改写、内容生成。
• 信息检索与问答：基于私有知识库的问答、行业知识助手。
• 流程自动化与决策辅助：根据输入数据自动执行操作、生成建议方案。
• 多模态理解与生成：图像识别、语音转写、视频内容理解。

不要急着上大模型。有些问题用传统规则、正则、向量相似度就能解决，成本更低、效果更稳定。AI不是目的，问题是目的。

3.2 判断哪些环节该用AI

第二步，把业务流程拆开，标出“规则可处理”和“需要语义理解”的部分。举例来说，客服工单系统里，工单分配可以用规则（按部门、按技能组），而工单内容理解、用户意图识别、知识库答案检索则适合用AI。好的AI应用设计，一定是规则和模型混用的。

这里有一个经验：能用规则就用规则，能用检索就用检索，只有在需要“语义理解和泛化生成”的时候才用大模型调用。这样既能保证可控性，又能控制成本。

3.3 设计数据闭环

第三步，考虑数据从哪来、怎么更新、怎么回流。很多开发者在写RAG时只关注向量化，却忽略了数据更新、去重、权限筛选等问题。真实业务里，知识库每天都在变，如果数据管道不健全，检索质量会逐渐退化。

数据层面的设计至少要包含：数据采集与清洗、分割与向量化、索引更新策略、用户反馈收集与再训练（或提示词优化）。

3.4 规划评估方式

第四步，定义“什么叫做好”。这个步骤是大多数AI项目最容易忽略的。模型输出没有固定标准，所以必须在项目启动就建立评测集——哪怕是100条带标准答案的样本，也足够在开发阶段发现回归问题。

评估维度可以包括：回答准确率、关键信息覆盖率、格式符合率、调用成本、响应延迟。后面章节会用示例演示如何做基础评测。

4. 一个AI应用实战：智能客服Agent的最小实现

下面用一个“企业知识库智能客服Agent”为例，演示从问题定义到代码落地的全过程。这个示例不依赖特定平台，核心用Python实现，模型部分按OpenAI兼容接口写，读者可以替换成任意大模型服务。

这个小项目要解决的问题是：企业文档分散在多个页面，员工经常找不到制度文件，客服组每天要回复大量重复问题，希望用一个Agent自动从知识库中检索答案并生成回复。它要验证的核心指标是：检索相关性和答案覆盖率，是否优于直接让大模型“裸答”。

4.1 系统设计

整个Agent分为四层：

• 数据层：存放知识文档，支持文本分割、向量化、检索。
• 工具层：提供检索工具（search_knowledge）、查天气工具（get_weather）、生成工单工具（create_ticket）等。
• 编排层：模型根据用户问题决定调用哪个工具、传入什么参数。
• 应用层：Web服务或命令行入口，接收用户输入，返回最终回复。

为控制复杂度，本文只实现检索工具和生成工单工具，并演示核心编排逻辑。

4.2 环境准备

建议使用Python 3.10及以上版本，安装以下依赖（版本以实际兼容为准）：

pip install openai numpy

如果做本地向量检索，可以直接用NumPy实现一个简单的余弦相似度检索，避免引入额外组件。生产环境再考虑Elasticsearch、Milvus或专用向量数据库。

4.3 代码结构

ai_agent_demo/ ├── main.py # 主入口，命令行交互 ├── agent.py # Agent 编排核心 ├── tools.py # 工具函数定义 ├── knowledge_base.py # 知识库构建与检索 ├── docs/ # 原始知识文档 └── eval_data.json # 评测集

4.4 知识库构建与检索

# 文件路径：knowledge_base.py import numpy as np class KnowledgeBase: def __init__(self): self.chunks = [] self.embeddings = [] def add_document(self, text: str, embedding: list): self.chunks.append(text) self.embeddings.append(np.array(embedding, dtype=np.float32)) def search(self, query_embedding: list, top_k: int = 3): query_vec = np.array(query_embedding, dtype=np.float32) scores = [] for vec in self.embeddings: score = np.dot(query_vec, vec) / ( np.linalg.norm(query_vec) * np.linalg.norm(vec) + 1e-9 ) scores.append(float(score)) top_indices = np.argsort(scores)[::-1][:top_k] return [(self.chunks[i], scores[i]) for i in top_indices]

这段代码的核心是余弦相似度检索。生产环境会替换为向量数据库，但原理一致：先把知识库文档离线向量化，运行时把用户问题向量化，然后做相似度排序。

4.5 工具函数定义

# 文件路径：tools.py import json import datetime def search_knowledge(knowledge_base, query_embedding, top_k=3): results = knowledge_base.search(query_embedding, top_k=top_k) return json.dumps( [{"content": content, "score": round(score, 4)} for content, score in results], ensure_ascii=False, ) def create_ticket(category: str, content: str) -> str: ticket_id = "TK" + datetime.datetime.now().strftime("%Y%m%d%H%M%S") payload = {"ticket_id": ticket_id, "category": category, "content": content} # 生产环境在这里调用工单系统接口，这里只做落盘演示 with open("tickets.log", "a", encoding="utf-8") as f: f.write(json.dumps(payload, ensure_ascii=False) + "\n") return json.dumps({"success": True, "ticket_id": ticket_id}, ensure_ascii=False)

工具函数是所有Agent动作的边界。把外部操作封装成工具，Agent只能通过这些工具影响外部世界，这是保证安全性的关键设计。如果Agent绕过工具直接操作数据库，风险会急剧上升。

4.6 Agent编排核心

# 文件路径：agent.py import json import openai from tools import search_knowledge, create_ticket SYSTEM_PROMPT = """你是一个企业知识库助手。 你可以使用以下工具： 1. search_knowledge(query_embedding: list): 检索知识库 2. create_ticket(category: str, content: str): 创建工单 当用户的问题需要依据知识库回答时，必须先调用 search_knowledge。 当用户要求生成工单时，调用 create_ticket。 如果工具结果不足以回答，请如实说明，不要编造。""" class Agent: def __init__(self, knowledge_base, embedding_fn, model="gpt-4o-mini"): self.knowledge_base = knowledge_base self.embedding_fn = embedding_fn self.model = model self.client = openai.OpenAI() def run(self, user_message: str) -> str: messages = [ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": user_message}, ] for step in range(5): response = self.client.chat.completions.create( model=self.model, messages=messages, tools=[ { "type": "function", "function": { "name": "search_knowledge", "description": "检索知识库", "parameters": { "type": "object", "properties": { "query_embedding": { "type": "array", "items": {"type": "number"}, } }, }, }, }, { "type": "function", "function": { "name": "create_ticket", "description": "创建工单", "parameters": { "type": "object", "properties": { "category": {"type": "string"}, "content": {"type": "string"}, }, "required": ["category", "content"], }, }, }, ], ) message = response.choices[0].message if not message.tool_calls: return message.content or "" messages.append(message) for tool_call in message.tool_calls: args = json.loads(tool_call.function.arguments) if tool_call.function.name == "search_knowledge": query_embedding = self.embedding_fn( user_message ) result = search_knowledge( self.knowledge_base, query_embedding ) elif tool_call.function.name == "create_ticket": result = create_ticket(args["category"], args["content"]) else: result = json.dumps({"error": "unknown tool"}) messages.append( { "role": "tool", "tool_call_id": tool_call.id, "content": result, } ) return "已达到最大步骤上限，请简化问题。"

这段逻辑的价值在于演示了Function Calling模式。模型不直接执行工具，而是输出“我想调用哪个工具、参数是什么”，由代码真正去执行，并把执行结果回传给模型，模型再决定下一步。这种设计保证了：

Agent 对外部世界的所有操作，都经过开发者定义的函数边界

开发者在实际项目中还要补充：工具调用的鉴权、超时控制、重试机制、敏感信息过滤、全链路日志。

4.7 主入口

# 文件路径：main.py import json from knowledge_base import KnowledgeBase from agent import Agent def load_docs(path): with open(path, "r", encoding="utf-8") as f: return json.load(f) def main(): kb = KnowledgeBase() docs = load_docs("docs/sample.json") # 生产环境这里应该使用 embedding 模型，例如 text-embedding-3-small for doc in docs: # 演示用伪向量，实际必须调用 embedding 接口 fake_embedding = [1.0, 0.8, 0.6] * 10 kb.add_document(doc["content"], fake_embedding) def embedding_fn(text: str): # 生产环境替换为真实的嵌入模型调用 return [1.0, 0.9, 0.7] * 10 agent = Agent(knowledge_base=kb, embedding_fn=embedding_fn) print("智能客服 Agent 已启动，输入 exit 退出") while True: user_input = input("用户: ") if user_input.strip().lower() == "exit": break answer = agent.run(user_input) print(f"Agent: {answer}") if __name__ == "__main__": main()

这里使用了伪向量，目的只是跑通流程。实际项目中必须接真实的Embedding模型，否则检索结果没有意义。

4.8 文档数据示例

// 文件路径：docs/sample.json [ {"content": "年假申请规则：入职满一年后每年享有5天年假，满五年后每年10天。年假需提前3个工作日申请。"}, {"content": "报销流程：员工在OA系统提交报销单，附发票照片，部门负责人和财务依次审批，审批完成后7个工作日内打款。"}, {"content": "工牌补办：如工牌遗失，请立即在OA系统挂失，并联系行政部补办，补办费用50元。"} ]

这是最小的知识库样例。有了这个，运行Agent后，它会先尝试调用检索工具，再基于结果回答。

5. 运行结果与效果验证

5.1 运行命令

python main.py

输入“年假怎么申请”，观察是否触发检索逻辑，最终回复是否包含“入职满一年后每年享有5天年假”等信息。

5.2 预期输出的核心特征

一个成功运行的最小Agent，应该满足以下特征：

• 模型返回的不是直接生成的内容，而是先发起了一次 tool_call。
• 知识库检索的结果被作为上下文传回模型。
• 最终回复中包含了知识库文档中的关键信息，而不是模型凭空编造的信息。

如果直接输入“年假怎么申请”，模型却给出“年假申请方式因公司而异”之类的泛泛回答，说明Agent没有正确触发检索工具。此时第一排查点应该是System Prompt里的工具使用说明是否清晰，其次是工具定义中的参数格式是否正确。

5.3 验证建议

为了量化效果，准备一份评测集，每条数据包含：用户问题、知识库应命中的内容、期望回答的关键要点。跑完评测集后，统计信息覆盖率。以下是一个简单示例：

// 文件路径：eval_data.json [ { "question": "年假有几天？", "expected_keywords": ["入职满一年", "5天年假"] }, { "question": "报销要多久到账？", "expected_keywords": ["7个工作日"] } ]

评测脚本逐个调用Agent，检查输出是否包含关键词。这一步虽然简单，但能防止后续修改提示词或模型版本后出现效果回归。

6. 常见问题与排查思路

以上是开发阶段最常见的几个坑。每一个都值得在实际项目中提前设计好对策。

7. 工程实践：把真问题做成可维护系统

7.1 需求侧：写一份“问题说明书”

项目启动前，建议写一份问题说明书，包含：

• 业务背景与现状痛点。
• 目标用户与使用场景。
• 成功指标（准确率、成本、延迟、人力节省等）。
• 失败边界（哪些问题Agent不应回答）。
• 必要的数据资源与权限。

这份文档的价值在于让所有参与者对“真问题”形成共识。没有它，技术侧容易陷入“能做什么就做什么”，业务侧容易陷入“什么都要AI做”。

7.2 工程侧：安全与权限边界

Agent可访问的每类数据、每个工具，都要做最小权限设计。比如知识库检索只能访问公开文档，工单创建需要二次确认，查询个人信息需要权限校验。真实项目中，这句“注意安全边界”不是套话——很多Agent事故都发生在工具调用越权上。

另外，建议对所有外部调用增加超时和重试。大模型服务可能出现延迟波动，工具调用可能超时。一个健壮的Agent在超时后应该选择降级方案，而不是中断整个会话。

7.3 工程侧：全链路可观测

Agent应用的调试难度远高于传统应用，因为中间多了一层模型决策。务必从第一天开始记录日志：

用户输入 -> 模型思考 -> 工具调用 -> 工具结果 -> 最终回复

每一跳都加上trace_id。这样一旦出现错误回复，才能回溯是哪一步出了问题。生产环境建议接入分布式链路追踪系统，开发环境至少打印结构化日志。

7.4 评估侧：先建评测集，再调模型

调Prompt、换模型之前，不要凭感觉判断效果。固定评测集，每次改动后跑一遍，对比分数。建议团队至少维护一个几十到几百条的真实问题集，并定期从线上日志中补充bad case。这是AI应用开发中最能拉开水平差距的环节之一。

8. 给开发者的下一步行动建议

如果你正在学习AI应用开发，不要急着学算法，建议按下面的顺序做一轮实践：

1. 用Python和OpenAI兼容接口写一个最简单的单轮Prompt调用，理解输入输出结构。
2. 实现一个本地知识库RAG，要求检索命中率可测量。
3. 用Function Calling实现一个Agent，至少包含一个外部工具，比如查询接口或工单系统。
4. 把同一个功能用不同的Prompt和模型各测一遍，建一个对比表格。
5. 部署到一台云服务器上，用Docker、Nginx和日志中间件搭一个最小生产环境。

做到第3步，你已经超过了只看教程不做项目的大部分人；做到第5步，你已经具备进入绝大多数AI应用岗位的工程基础。

再回头看亦庄和杭州的这两场活动：产业侧需要的，是能把“工厂质检”“客服降本”“知识沉淀”变成稳定系统的AI工程能力；青年一代争论的循环上限、幻觉抑制、Agent安全边界，本质上都是这类工程能力的前置问题。36氪把这道题交给年轻人，意味着AI的话语权正在从“模型发布者”转向“问题解决者”。对CSDN的读者来说，这恰恰是机会：与其追逐新模型发布的节奏，不如把一批真问题钻研透，用工程能力建立自己的位置。