企业官网建设流程全解析

把"敏捷"和"智能体"放一起，很多人第一反应是又要玩概念了。但我最近在几个项目里反复验证了一套打法定型下来：从立项到能演示、能评测、能让业务方说"先用用看"的智能体，45天不是上限，反而是一个特别合适的节拍器。我见过太多团队立项时说要做Agent，结果三个月过去还在"验证底层能力"，模型换了三个，框架讨论了几轮，业务场景剩下PPT上那一页。问题不在技术难度，而在没有给"验证"这件事本身设一个时间盒。

这篇文章就是围绕这套45天落地方案展开的。我会把这套方法拆成六个部分：时间盒怎么定、底座怎么砍、场景怎么挑、验证怎么数字化、交付前要补哪些功课，以及我自己踩过最容易翻车的那几个坑。适合谁看？如果你正准备在企业里上智能体，或者已经启动但感觉节奏失控了，这篇能给你一张可以直接照做的路线图。

1. 45天从哪来：时间盒、范围冻结与最小验证闭环

1.1 智能体项目为什么不能按老路子排期

传统软件项目哪怕需求再模糊，好歹交互路径是确定的——按钮点了会跳转，接口传了参数会有响应。智能体完全不一样，它最大的特点是：你不真正跑起来，就不知道模型会怎么理解你的业务指令。同一个Prompt，在某条样本上表现很好，换一种问法可能就完全跑偏。这种不确定性意味着，需求文档写得再细，也只能描述"我们希望它做什么"，没法描述"它实际会遇到多少种奇怪的输入"。

所以智能体项目天然适合敏捷，而且比普通软件更需要短期冲刺。把周期拉到三个月以上，最典型的后果是"需求漂移加集成黑洞"：业务方每周提新想法，开发的Demo停在60%的完成度，真正该做的错误处理、边界测试、性能优化全被挤到最后一刻。45天这个时间盒，本质上是把"发现需求"这件事前置，用不断跑真实样本替代开长会讨论需求。

1.2 45天的拆解依据

我排45天不是随便一拍脑袋。按我这几轮项目复盘的常见经验，一个5人上下的小团队（1名产品、1-2名后端/算法、1名前端、业务方兼职投入），45天大致可以切成这样：

这里每个阶段都有冗余，比如第10~24天如果提前完成，可以把时间让给后面的打磨；如果延迟了，第39~45天就要砍掉非核心功能。关键是不让任何一段无限膨胀。

1.3 范围冻结：MVP就是"一条链路走通并能量化"

想45天跑起来，第一刀就要砍在范围上。我一般跟团队约定：

• 只做一个场景，不做"总入口"或"万能助手"。
• 只接2~3个外部工具，比如查订单、查文档、写工单。
• 只支持一种交互入口，比如对话框或工单表单，不做语音、不做多轮复杂流程编排。
• 只承诺"结果可以看，错误可以认"，不承诺效果100%正确。

换句话说，MVP的定义不是"实现了多少功能"，而是"有没有一条可演示、可评测、能回答真实业务问题的核心链路"。只要这条链路通了，项目就成功了大半，剩下的都是迭代问题，而不是方向问题。

2. 第1周半：底座只做"够用"，不碰企业级平台

2.1 模型选型：接口兼容比参数大小更影响进度

很多团队一上来就在几个大模型之间反复横跳，今天试一个，明天试另一个，光选型就花了两周。我的做法恰恰相反：先定一个"接口兼容"原则——所有上层代码都走统一的接口抽象层，模型本身换成谁都行。这样选型就变成"先选一个主流均衡型模型，跑通再说，后面随时可以换"。

具体选型时，我通常只看四件事：

• 这个模型的接口协议是不是OpenAI兼容。不是的话，SDK适配要额外花时间。
• 上下文窗口够不够装下我们的系统提示词加业务资料。最少16K起步，32K更稳。
• 有没有靠谱的托管或部署方式，直接在内部环境访问，别为了一套API申请流程耗一周。
• 单位token价格和响应速度是否可接受。智能体是多轮交互，一轮消耗几十万token，价格敏感度比普通问答高一个量级。

我的建议是：小样本试跑阶段可以用性价比较高的模型快速验证场景，等验证完再决定是否把核心链路切换到更贵的旗舰模型，而不是一开始就追求最强推理能力。

2.2 Agent骨架尽量薄：先做Workflow，再做Agent

见过太多团队在底座阶段就铺开"多Agent协作、记忆系统、规划器、工具自动发现"这一套。大厂文章看了不少，自己团队也热血沸腾，结果光把这些模块的接口对齐就耗掉两周。以我的经验来说，45天项目里，第一个版本根本不需要什么复杂智能体框架。

你只需要一个很薄的调度逻辑：

def run_agent(user_input: str, tools: list[str]) -> str: # 1. 判断意图，决定是否需要调用工具 intent = classify(user_input) # 2. 如果需要，提取参数并调用工具 if intent.need_tool: params = extract_params(user_input) tool_result = call_tool(intent.tool_name, params) # 3. 把工具结果塞回上下文，生成最终回答 prompt = build_prompt(user_input, tool_result) return llm_chat(prompt)

这段代码的价值不在于它能处理多复杂的情况，而在于它把"决策""调用""回答"三个环节彻底拆开了。哪个环节出问题，日志一眼就能看出来，回归测试也好定位。等验证完场景、确认非要用Agent不可，再引入正经的Agent框架也不迟。

2.3 工具链就三样：日志回流、少量业务资料、评测脚本

底座阶段别碰知识库大工程。很多团队第一个月就花在清理文档、做chunk、搭向量数据库、调召回参数上了，这是典型的把"资料治理"误当成"智能体开发"。45天内，你只需要：

• 一份最小业务资料集。挑跟场景最相关的几个文档或表格，总量控制在几十页之内，塞进一个最小的向量检索组件，或者干脆作为上下文片段直接拼进Prompt。
• 一套结构化日志。每一轮的输入输出、工具调用参数、token消耗、耗时、错误码全部落地。没有这个，后面评测和优化根本无从谈起。
• 一个评测脚本。几十条真实case，给每条写好预期行为，跑一遍自动打分。第1周就搭好，后面每天跑，比什么花哨都管用。

记住：底座的验收标准不是"架构先进"，而是"部署链路通、日志能回流、评测能跑、改Prompt能迭代"。任何一个新同学接手后能一天内改一版，这个底座就算合格了。

3. 第2~4周：挑一个窄场景，把第0版跑出真实结果

3.1 场景筛选：高频、有交付物、错误容忍度适中

底座就位后，最大的败招是试图把智能体做成"什么都能聊"的入口。你的目标恰恰相反：找一个足够窄的业务切口，窄到你可以在两周内亲手标注几十条case、摸清所有常见用户问法。

我筛选场景时一般用下面这张表打分：

我用这个标准在好几个项目里筛过场景，选出来比较靠谱的是这类：内部IT支持问答、订单状态查询、报销单填写助手、知识库文档检索问答。这类场景共同特点是：问法相对固定、答案基本有据可查、错了也不会造成灾难性后果。

那些看起来光鲜但不适合首发的场景也要说清楚：跨系统联动的"综合办事入口"、需要写库改数据的"自动化执行Agent"、涉及多轮复杂谈判类交互——这些最好是45天跑通核心链路之后，二期再扩。

3.2 第0版的设计原则：规则前置、少工具、强输出约束

第0版不是用"自由智能体"去对着大模型祈祷它表现好，而是像一个受过训练的新员工：有规范、有边界、答不上来就说答不上来。

我写第0版提示词时，一定会包含这几样东西：

• 角色和边界说明：你是谁，你只回答哪类问题，超出范围如何拒绝。
• 业务判断规则：所有能写成If-Else的不是交给模型自由发挥，而是前置到代码里。
• 少样本示例：2~3个完整的"用户问法→工具调用→最终回答"案例，必须包含一个反例。
• 输出格式约束：要求JSON或固定模板，方便后续校验和解析。

一个典型Prompt片段长这样：

你是某部门的知识助手，只回答关于员工报销和差旅制度的问题。 当用户包含金额、日期、事由时，你需要提取并按此JSON输出： { "need_tool": true, "tool_name": "query_reimbursement_policy", "params": {"amount": "", "date": ""} } 反例：当用户问"帮我写首诗"时，你需要直接拒绝并说明自己只回答报销相关问题。

把约束写在提示词里，比在代码里堆一堆if判断更快迭代，也比完全放飞模型更稳定。第0版只要能跑通这个链路、输出格式稳定、大部分case能给出可用的回答，就算过关了。

3.3 第0版的验收：50条case跑通70%以上就进入迭代

我看到很多人做智能体时，总想第一阶段就做到95%的准确率。这是不现实的，因为很多失败case只有跑到真实反馈里才能暴露出来。我给团队定的第0版验收线很务实：用50~100条真实历史case做评测，核心任务完成率达到70%就算可以进入下一阶段。

70%这个数字看起来很低，但它告诉你三件事：第一，场景选对了，模型确实能处理大部分需求；第二，剩余的30%是明确的迭代方向，不用再猜；第三，业务方可以开始试用，从真实反馈里捞之前没想到的case类型。注意，这70%必须是"真实case"，不是你们自己编的理想例句。

4. 让"表现"变成数字：评测集、埋点与回归节奏

4.1 评测集怎么建：真实历史case为主，人工标注好中差

评测集是整个45天打法里最容易被低估的环节。没有评测集，你改了一版Prompt，到底变好了还是变坏了，全凭感觉，这种感觉在智能体项目里最不靠谱。我建评测集的办法很简单：

• 从业务方手里拿历史记录。客服聊天记录、工单、问答记录，哪怕没有标准答案，也可以做"参考回答"。
• 人工对每条case标注好、中、差三个等级。"好"指直接可用，"中"指方向对但需修改，"差"指完全不能交付。
• 覆盖常见问法，同时留20%~30%的比例给边界和异常case，比如超长问题、非业务问题、指代不明问题。
• 集数不求多，初期100条足够，但要坚持"只增不减"，每次新增真实case后放进评测集。

评测标准可以简单定义成：回答可接受率 = （好 + 中）/ 总case数。不需要做得很学术，够团队内部对比版本就行。

4.2 三个数字够了：任务完成率、人工介入率、单次成本

有的团队一上来就搞意图准确率、情感分析、响应质量评分、rag召回率、推理耗时……十几个指标列了一整屏，最后没人看得懂。我建议45天内，只盯三个数字：

这三个数字足够支撑你判断"这版改得值不值"。比如完成率从70%涨到80%，但单次成本涨了三倍，这种"提升"就要掂量一下了。反过来，人工介入率只要还能维持在可接受范围，完成率稍微波动就不可怕。

4.3 日志埋点的最小设计：每一步都可回放

智能体最大的调试困难在于它是个黑盒。Prompt改了一句话，可能把另一个case搞挂，而且你还不一定知道为什么。所以埋点必须做到"每一步都可回放"。

发给模型的完整Prompt、模型返回的原始内容、工具返回结果、模型最终输出、本轮token和耗时，这些每次都要原样落库。我这轮项目用的日志结构大概是这样：

{ "trace_id": "a1b2c3", "user_input": "上个月打车费什么时候能报销", "prompt_version": "prompt_v12", "llm_request": {"model": "gpt-4o-mini", "tokens_in": 5230}, "llm_intermediate": "{\"need_tool\": true, ...}", "tool_call": {"tool": "query_policy", "params": {"amount": null}}, "tool_result": "差旅报销最长不超过90天", "final_answer": "上个月的打车费可以报销，建议在90天内提交申请。", "token_total": 10480, "latency_ms": 2400, "satisfaction": "good" }

有了这份日志，任何case出问题，你都可以把整条链路回放一遍，直接看到是哪一步跑偏，而不是靠猜。

4.4 迭代节奏：每天一次小回归，每周一次业务方验收

45天项目里，迭代节奏要像拧紧发条一样稳定。我的习惯是：

每天下午拉一次评测结果，看可接受率是涨是跌。如果跌了，当天定位原因是新改的Prompt影响到了哪类case，立刻回滚或修正。每周约业务方看一次真实案例演示，不演示成功的案例，专门演示本周进步和还搞不定的case，从业务方嘴里拿到反馈。

这么跑的节奏看似平淡，但40天后回顾会发现：真实case每天以5~10条的速度进评测集，完成率从65%一路波动着涨到85%，模型换了两次、Prompt迭代了二十几版，每个决定都有数据支撑。

5. 最后两周的落地功课：交付清单、兜底设计和成本复盘

5.1 交付不是"演示成功"，而是"拿掉demo滤镜"

第0版只要在验证阶段表现稳定，接下来就要进入真正的落地交付阶段。这个阶段我特别提醒团队注意一件事：Demo跑得好和真实环境好用是两码事。

真实环境里用户问法更脏、系统接口更慢、并发更高、权限更复杂。所以最后两周，我一般会把主要精力放在三个方向上：响应速度和超时处理、异常输入拦截、权限和数据边界检查。比如给Agent加一个"超时兜底"，工具调用超过5秒就返回"系统繁忙，请稍后再试"，而不是让用户对着转圈页面傻等。

5.2 检索能力做"务实版"优化，而不是重建知识中台

如果场景里涉及知识问答，这个阶段常见的瓶颈是检索质量——有时候不是模型不会答，而是根本没把对的内容给到模型。此时再去做大规模知识治理、嵌入模型重训已经来不及，我就做几件务实的事：

• 调大候选召回数，让模型看得更多，判断更准。
• 调整文档切块策略，把原本按固定长度切块的文档改为按标题和段落语义切块。
• 加关键词和向量混合召回。很多内部文档包含专业缩写，纯向量检索容易漏，配合关键词能显著提升命中。

这几项改动一般不需要动底层架构，但对最后几周的完成率提升特别明显。

5.3 人工兜底不要藏着：置信度低就转人

智能体做不到100%正确，但如果它答错了还一本正经地给用户发过去，业务方和用户的信任会在第一次翻车时掉到谷底。所以交付前一定要有"兜底"：

• 当识别到用户意图不在支持范围内，或提取出的关键参数不完整时，先不急着编答案，直接回复标准话术："这个问题我需要人工确认，已为你转接。"同时自动生成一条待办给人工处理。
• 设置置信度阈值。如果模型对生成的回答不够确定，最简单的方式是让它在输出JSON结果时附带confidence字段，低于某个阈值就自动转人工，而不是硬着头皮答。
• 人工侧给一个简单的处理面板，集中处理转人工的任务，别让用户等太久的反馈。

我在上一个项目里加了这条兜底之后，那块Agent的可用性从"偶尔可用"变成"基本可用"。因为用户宁可看到一次诚实的转人工，也接受不了一个自信满满的幻觉回答。

5.4 上线前的检查清单

最后交付给业务方之前，我会过一遍检查清单。这张单子不一定每条都适用，但至少有参考价值：

这套检查清单帮我挡住了不止一次生产事故——比如某次差点让Agent直接读取了它权限之外的数据库，就是因为权限边界卡了一下才拦住。

6. 这套方法论在真实项目里最容易踩的坑

6.1 评测集过拟合：Agent会"背答案"

这个坑我做第三轮项目时才发现。前几轮评测集一直涨，可真实用户来了还是翻车，后来一查原因：评测集里反复出现的那批case，模型在提示词的少样本例子里"见过"了，等于把答案背了下来，看着准，实际没学会。后来我加了一条规则：评测集分A、B两组，A组可以放少量样本进提示词，B组严格不进上下文，每次只用来验证真实泛化能力。不然测试成绩全是自我安慰。

6.2 上下文污染："假记忆"比"没记忆"更致命

智能体跑一段时间后，多轮会话里前面聊的无关话题会挤占上下文窗口，甚至把系统提示词里的关键规则给"挤"出去。最典型的翻车现场是：用户前面问了几句完全不相关的东西，后面再问业务问题，Agent突然忘了自己的边界，开始胡回答。

我的对策很简单：每轮对话都动态拼Prompt，只保留系统指令和最近两轮对话，更早的内容要么通过工具结果摘要带入，要么直接丢弃。不要图省事把整个历史全部塞进上下文。必要时给Agent加一条"每轮任务独立"的约束，让它别把上一轮的情绪带入下一轮。

6.3 工具调用的"静默失败"：错误被吞掉

智能体调工具失败时，模型有时候不报错，而是顺着错误结果继续编。比如查订单接口超时，返回了一个空对象，模型就在那乱猜"可能没有这个订单"。这种静默失败比明确报错更坑人，因为它会让你误以为流程是顺的。

后来我养成了一个习惯：工具返回必须带上成功/失败标记，凡是失败结果，Prompt里写死"如果工具返回异常，直接转人工，不要猜测原因"。就这一条，把不少暗坑都堵上了。

6.4 效果波动导致团队失去信心

最后说的是团队心态问题。45天不可能是一条向上的直线，中间一定会有那么几天评测集数字往下掉。你本周加的新工具可能让某个老case挂了，下周改了提示词可能又带偏了两个样本。这个阶段团队里容易冒出"我们是不是方向错了"的声音。

我的处理办法很朴素：把所有变更都记录成"实验"，每周复盘时只看趋势，不看单点波动。只要长期上涨，中间跌几个点完全正常。坚持跑完45天，你会发现大部分被质疑的方向，其实就差再迭代几个版本。

我连续跑了几轮这套打法之后最大的体会是：智能体能不能落地，多数情况下不是模型能力的问题，而是"有没有敢砍范围、敢定时间盒、敢用数字说话"的问题。45天把你逼到必须做减法，而做减法恰恰是这类项目最稀缺的能力。如果你手里正有这么一个智能体项目在挣扎，不妨试试把这篇文章里的每一条当成一个检查项，逐一对照看看，你大概率能砍掉一半以上的无效工作。