答辩前一周我们项目文档的标题还叫《基于视觉感知与物联网数据的龙虾养殖辅助系统》直到演示前一天才改成《养一只自己的龙虾吧》。为什么改因为评审看了十分钟PPT最后记住的关键词只有“龙虾”什么“多模态感知”“决策闭环”一个没记住。这次参加高校AI智能体创新大赛的经历是我们几个人在大学期间做过最值的一次项目——我们真的把一个会看数据、会推理、会聊天的AI智能体“养”了出来而且在一群做内容助手、通用问答机器人的队伍里靠一只龙虾杀出了辨识度。这篇文章想把整个项目从头到尾复盘一遍包括选题思路、核心模块拆解、联调阶段踩过的坑、答辩现场被追问的问题以及如果让我再参加一次会怎么做。适合正在准备各类AI创新赛事的同学参考也适合所有想了解一个“完整智能体应用”到底由哪些环节组成的人。1. 从“养龙虾”这个点子到正式立项我们盯上了大家都不愿意碰的领域1.1 为什么别人都在卷智能助手我们却选了个养殖场景那届智能体创新大赛的要求很简单做一个能解决真实问题的AI智能体提交方案文档、演示视频现场答辩。我看了往届优秀作品清一色是个人助理、知识库问答、代码生成助手、客服机器人。不是说这些不好而是同质化太严重评委看十个队有八个在做同一件事后面的队伍很难拉开差距。我们队四个人当时列了一个候选清单医疗问答、校园服务助手、农业养殖、二手交易解析、自习室预约智能体。划掉校园和自习室这两个“安全牌”之后我们把目光放在农业养殖上。原因是和学校附近的一家养殖基地有过合作基础那边愿意开放场地和数据给我们做调研。更重要的是养殖这个场景里智能体的价值链条非常清晰环境数据需要感知生长情况需要判断病害问题需要分析日常管理需要建议——这不是单一模型能搞定的恰恰是智能体这种“工具编排对话交互”的形态最擅长应付的问题。你去看那些大而全的智能体产品什么都想做最后什么都做不深。养殖不一样它有一个非常具体的实体对象龙虾。我们后来的项目名“养一只自己的龙虾吧”其实藏着两层意思一层是帮助养殖户养好真实的龙虾另一层是让普通用户认养一只虚拟龙虾由智能体根据真实环境和生长数据驱动它的状态变化相当于把严肃的养殖管理做成了有温度的产品。1.2 走访养殖基地后我们提炼出的三个核心痛点立项之前我们去做了一次实地调研和基地的负责人聊了整整一个下午。他说的几件事我到现在都记得很清楚第一个痛点是水质判断全凭经验。他说自己入行八年看水色就知道要不要换水但新招的工人完全看不懂只能靠浑浊程度猜经常判断失误。水温、pH、溶氧、氨氮这些指标不是没有仪器而是仪器只负责把数字显示出来没有人告诉工人“这几个数字组合在一起意味着什么”。第二个痛点是生长数据几乎没有记录。一池龙虾养了三个月绝大多数养殖户只记得总产量和总饲料投入完全不知道个体规格分布是怎么变化的、什么时候出现了长势分化、哪些批次可以提早上市。没有数据就谈不上优化投喂策略。第三个痛点是病害发现得太晚。龙虾染病初期外在表现非常细微工人巡塘时用肉眼很难看出来等明显发病往往已经扩散了。这三个痛点摆在一起你会发现它们正好对应智能体的三个核心能力感知视觉识别物联网数据、分析生长模型水质诊断、交互用自然语言给出可执行建议。所以我们在立项答辩时给评委的核心逻辑是智能体不是做出来“炫技”的而是因为农业养殖的天然复杂性本身就要求各环节联动单做一个识别App解决不了问题。1.3 立项时我们反复自问的三个问题确定场景之后我们内部开了三次会每次都在过三关这项目完成得完吗赛程给了两个半月。视觉识别、生长预测、知识库问答、Web前端、演示部署哪一项单独拿出来都不算难合在一起就是个大工程。我们最后把范围严格控制住了不做多智能体协作不做复杂权限管理不做移动端只做一条闭环——环境数据进来视觉模型判定个体状态生长模型预测趋势大模型整合输出建议。数据从哪来这是最大的风险点。基地同意帮我们采集环境数据但视觉训练需要大量带标注的现场图像我们一开始低估了工作量实际上光标注就花了两周。凭什么说这是“智能体”而不是普通软件这是我们在文档里反复强调的区别整个系统不是固定规则触发的而是用户在自然语言对话中提出目标由大模型自主判断需要调用哪些工具、检索哪些知识、给出什么建议。工具是插件式的后续可以不断扩展。这三关都想清楚了我们才正式把名字定为“养一只自己的龙虾吧”准备开干。2. 三个核心模块拆解视觉体检、生长预测、对话式养殖顾问2.1 视觉体检模块教智能体“看”一只龙虾视觉模块是“养龙虾”里最直观的部分主要做两件事检测画面里的龙虾个体判断它的规格和状态。我们在养殖池上方布了两个固定摄像头和一个补光灯每隔10秒抓拍一帧持续采集了两周筛选出有效图像3000多张。标注内容包括三块目标位置框、体长等级以已知直径的PVC管做参照物换算、状态标识正常/蜕壳/疑似患病/活跃度低。模型选型上我们没有追求最先进的大结构而是选了轻量级目标检测框架做迁移学习用预训练权重初始化只在我们的数据上微调了全部层。这样做的原因有两个一是数据量不大从头训练小模型容易欠拟合二是答辩现场用的是普通笔记本大模型推理速度撑不住演示。推理部分代码非常简洁import cv2 from detector import load_model, run_inference model load_model(lobster_det.pt) frame cv2.imread(pond_latest.jpg) boxes, labels, scores run_inference(model, frame, conf_threshold0.45) for box, label, score in zip(boxes, labels, scores): length_cm estimate_cm(box, ref_pipe_cm5.0) status classify_status(frame[box[1]:box[3], box[0]:box[2]]) print(fdetected {label}, conf{score:.2f}, est_length{length_cm:.1f}cm, status{status})在实际测试集上我们最后的mAP在0.85左右体长估算误差能控制在2厘米以内。这对辅助决策完全够用但训练过程中也暴露了一个问题水下图像有折射导致测量偏差室外光照变化会让误检率飙升。我们后来加了白平衡校正和参照物动态标定误检率才降下来。这里必须提醒一句视觉模块80%的时间不是在调模型而是在处理图像采集环境和标注质量的问题这部分时间一定要提前预留。2.2 生长预测模块用环境数据推算“这周该喂多少”养殖基地提供了三个多月的传感器历史数据字段包括水温、pH、溶氧、氨氮、投喂量、光照时长每10分钟一条。我们的目标不是做精确到克的预测而是预测未来一周的个体平均体重增长率然后转换为投喂调整建议。模型选型时我们放弃了一上来就上时序神经网络的想法。理由很直白数据量只有几千条LSTM这类模型在小样本上很容易过拟合更关键的是养殖户需要知道“为什么这么建议”树模型可以直接输出特征重要性“水温影响最大溶氧其次”这种结论本身就能给养殖户带来认知增量。特征设计上我们没有把原始10分钟粒度的数据直接灌进去而是先做了聚合过去7天的平均水温、最高水温波动、平均溶氧、最低溶氧、平均pH、平均氨氮、累计投喂量、近三天投喂变化率。目标的特征工程比模型本身更重要这话在结构化数据场景里永远是真理。最终用的是LightGBM做回归预测未来7天体长增长率平均绝对百分比误差在15%左右。对于一个辅助决策工具来说这个精度已经能提供不错的参考价值特别是当模型输出趋势判断“未来一周生长速度会放缓”而不是绝对数值时养殖户更容易接受。这里放一下特征表和模型输出的配合逻辑特征采样粒度在系统中的用途水温10分钟生长预测、病害风险预警溶氧10分钟缺氧预警、投喂建议pH10分钟水质趋势判断氨氮10分钟水质恶化预警投喂量按天记录生长预测、成本分析光照时长按天统计生长节律参考模型跑出来的结果会和视觉模块的个体状态识别做交叉验证如果视觉告诉你龙虾活跃度下降环境数据又显示溶氧偏低系统就会给出一条综合预警而不是只看单一数据源。2.3 对话式智能体模块让用户觉得自己在和一个懂养殖的人聊天这是整个系统最“智能体”的部分。我们设计了一条工具调用链路用户提问后先经过一个规则过滤器把简单查询直接分发给对应工具比如“水现在多少度”直接查数据库返回只有复杂问题才进入大模型做意图理解和任务规划。这么做是有教训的。最初我们全部交给大模型自由调用工具结果用户问“水温多少”模型绕了一大圈调用了生长预测工具答非所问还浪费token。加了一个意图分类前置之后这种低级错误基本绝迹了。我们对大模型的系统提示词做了非常严格的设计核心内容是这样的你是“养一只自己的龙虾吧”的智能养殖顾问。 你可以调用以下工具 - vision_check: 分析最新池塘图像获取龙虾个体状态 - query_water: 查询最新环境数据和历史趋势 - predict_growth: 预测未来一周生长情况 - search_knowledge: 检索养殖知识库 规则 1. 用户询问实时状态时先调用对应工具基于工具返回结果回答禁止编造数字。 2. 只有工具返回异常时再结合知识库给出处理建议。 3. 涉及用药建议时只提示咨询专业兽医不直接给治疗方案。 4. 回答必须附带数据来源例如“根据今天上午10点的水质数据”。知识库方面我们整理了常见病害图谱、水质管理手册、龙虾习性资料、养殖常见问答一共约两百多个条目切分后存入向量库采用检索增强生成的方式让大模型在回答具体养殖问题时先检索再作答。效果非常明显模型的幻觉率大幅下降很多之前会随口乱编的答案都会变成“我去查一下养殖手册再回答你”。整个对话过程用户感知是问一个模糊问题“我的龙虾最近不怎么动”智能体会自动去调视觉分析、查水质、看生长预测然后给出复合回答——“视觉检测发现活跃度偏低近三天溶氧均值略低于正常水平预测下一步生长速度会放缓建议先加大增氧今晚减少投喂量观察一下。”3. 开发和联调阶段数据、识别、任务编排三个大坑3.1 网上找来的数据集根本不能用这是整个项目我们摔得最疼的一跤。刚开始训练视觉模型时为了快点跑通流程我们直接从公开网络上下了一堆龙虾图片凑数据集。当时觉得“AI不就是这样吗网上找数据标一标训练”结果第一版模型在真实养殖池画面上的表现惨不忍睹识别率低到队友想放弃。回头分析原因其实不复杂网上的龙虾图大多是菜品图、养殖环境特写、标本图拍摄角度在正上方俯拍的极少背景干净整洁水色清晰而我们实际场景里的水面有浮游生物、有气泡、有阴影画面杂乱得多。领域偏移(data domain shift)四个字我们用了十几天才真正体会到。后来我们调整策略在基地架设了两台设备做定向采集专门模拟真实使用场景再配合弱光条件下的补光增强才逐步把识别效果拉回来。这个过程让我彻底明白了一个道理AI项目的效果上限从来不是在模型网络结构上决定的而是在数据采集和数据标注阶段就定死了。后面有人再问训练技巧我会先问一句你的数据和真实推理场景匹配吗3.2 视觉模型从“能跑”到“跑得动”的取舍比赛现场答辩的电脑是我们自己的笔记本性能有限。最初的实验版本用的是较大尺寸的检测模型精度不错但在CPU上推理一帧要好几秒如果是GPU也才勉强达到每秒十几帧。现场演示如果卡到这种程度评委体验会很糟糕。我们花了大概一周时间做模型轻量化先换用更小的输入尺寸再尝试了不同规模的网络结构最后选定了一个在精度和速度之间相对均衡的版本。实测在笔记本GPU上能达到每秒20帧左右的推理速度展示效果足够流畅。另外我们把“识别到龙虾后的状态分类”拆成了一个更小的分类网络这样目标检测只需要负责定位状态判断可以并行处理整体延迟反而降了30%。还有两个工程细节值得分享一是摄像头抓拍时间不固定如果正好在投喂导致的浑浊期抓图效果会很差我们干脆把抓拍逻辑改成“水质浊度超过阈值就跳过本帧”从源头减少脏数据二是现场演示时网络环境不可控我们把视觉服务改成了本地调用所有模型文件随项目打包确保断网也能演示。3.3 智能体“乱调用工具”和联调阶段的降级方案联调阶段最大的麻烦不是模型效果而是“模型行为不可控”。最开始我们让大模型自由选择工具调用结果出现各种诡异行为用户问“氨氮高了一点是怎么回事”模型没查工具就直接根据常识回答而且数字是编的用户问“最近适合上市吗”模型调用了视觉分析工具其实应该先查生长预测和市场价格趋势;用户闲聊“今天天气不错”模型也尝试调用工具。这些问题如果不解决答辩现场很可能翻车。我们逐步加了三层护栏第一层是刚才提到的规则过滤器把60%的简单查询挡在模型调用之前不消耗token也不给模型犯蠢的机会。第二层是工具结果强制注入。模型只能基于工具返回的真实数据进行回答不能自由发挥数字。我们在实现上把工具返回的JSON结构化为上下文片段拼接到模型生成的请求里并要求模型“如果数据不足以回答直接说信息不足”。第三层是服务降级。视觉服务挂了智能体自动提示“视觉模块暂不可用正在基于环境数据和历史记录回答”生长预测服务挂了就只提供水质分析和知识库建议。这样即使演示现场某个服务崩溃系统还是能维持一段对话不会整个白屏。这层设计评委后来专门提过说“至少你们考虑了产品在真实世界里会挂的情况”。系统架构经过这轮折腾后稳定成了下面这个结构模块职责技术选型Web前端认养页面、监控面板、聊天界面Vue轻量版后端API接口路由、用户会话管理FastAPI智能体编排意图过滤、工具调用、回答生成大模型API 规则过滤器视觉服务目标检测、个体状态识别轻量级YOLO 分类网络数据服务传感器数据存取、生长预测LightGBM PostgreSQL知识库养殖资料检索向量库 RAG4. 比赛现场评委问得最多的问题我们怎么接住的4.1 “你们用的模型不都是现成的吗创新点到底在哪”这个问题几乎每个做应用型项目的队伍都会被问到。我们当时的回答分了三个层次第一创新不在于模型而在于把目标检测、生长预测、知识检索、大模型对话这四类能力编排成一个能自主决策的闭环这是传统的单一模型应用做不到的第二我们在养殖领域做了数据层面的深度适配包括现场数据采集标注、领域知识库构建、体长测量标定这些脏活累活恰恰是通用模型落地的真正壁垒第三产品形态本身是创新的同时服务养殖户和普通用户这个定位在比赛现场没有第二家。最后我又补了一句如果创新只能是“从零发明一个模型”那绝大部分工程类项目都不该参赛了。实际上的创新大赛看的应该是解决问题的能力。4.2 “识别准确率不够高养殖户怎么敢用”这个问题很尖锐。我们没有回避直接说了真实数据当前体长估算误差在2厘米左右状态识别置信度低于0.45时会自动标记为“无法判断”不会硬给结论。我们设计的逻辑是“低置信度时建议人工复核”而不是让系统强撑着做判断。评委追问生产环境能不能做到90分我们坦诚地说不能但我们的目标不是替代养殖户的经验而是帮新手快速接近老师傅的判断水平同时用数据把经验沉淀下来。评委对这个态度是认可的。4.3 “不做成大模型对话做个传统软件不也可以吗”这个问题其实是我们最有底气的。传统软件的逻辑是固定流程界面里一堆按钮用户自己选择“查水质”还是“看生长曲线”。但我们这个场景里用户往往不知道自己该先看什么更不会把多个指标组合起来分析。智能体的价值就在于用户只需要用自然语言描述一个模糊目标系统会自动完成多步检索和工具编排。养殖户文化水平普遍不高让他们对着十几个图表做判断不现实。而对话问答的方式几乎零学习成本这就是“大模型工具调用”不可替代的地方。4.4 “项目成本多少能真的落地吗”我们在基地做了小范围实测硬件成本主要是一路摄像头、一个水质传感器集成箱、一台本地推理主机整体采购成本不算高。大模型API按调用量计费我们做了规则过滤器之后每天的调用量其实很有限。所以单点部署成本可控一个小型养殖池完全承担得起。我们不吹它能全面替代人工而是定位成辅助工具提供更早的预警和更系统的数据记录把“经验”变成“经验数据”。基地负责人试用后的原话我记得很清楚“以前我看水色是猜现在你们这个系统能让我多一个判断依据挺好的。”对我们来说这已经是最好的反馈。4.5 “你们的智能体现在一个人工智能体也没有算不算套壳”问这个问题的是一个看起来懂行的评委当时我们多少有点窘。冷静下来后我们回答大语言模型是智能体的大脑但智能体本身的定义是由环境感知、决策规划、工具行动构成的循环我们实现了感知输入、规划工具调用、生成反馈这个循环这已经具备智能体的核心结构。我们承认还没有做多智能体协作和长时间自主规划这是未来方向但如果拿着“多智能体才算智能体”的标准市面上大部分参赛项目的复杂度都不够看。后来我复盘觉得这种诚实的回答反而比强行辩护加分评委要的不是你完美无缺而是你是否清楚自己的边界在哪里。5. 复盘与建议如果再参加一次我们会做哪些不一样的事5.1 时间线和人力分配工程项目的排期全部踩歪了这是我们的真实排期表对比一下就知道哪些环节被低估了阶段计划耗时实际耗时超支原因选题与方案设计1周2周反复纠结场景数据采集与标注1周3周真实场景采集困难视觉模型训练2周2周还算正常生长预测建模1周1.5周特征工程返工智能体编排与后端2周3周工具误调用调优Web前端与联调2周2.5周演示稳定性修复文档与答辩准备1周1周基本压线完成总时长比预期超了将近两周最后能赶在截止时间前交完全靠压缩休息时间。回过头看最应该提前做的是数据采集因为真实场景里的图像质量、标注一致性、环境干扰这些不确定因素太多必须给它们留出足够冗余。5.2 三个明确的教训先解决数据再谈模型先跑通闭环再优化细节第一个教训是数据优先。我们早期花了大量时间比对各种模型的精度差异后来发现只要训练数据和真实场景匹配哪怕模型结构普通效果也差不到哪去。反过来数据质量不行的时候换什么模型都没用。第二个教训是先纵向跑通闭环再横向加功能。我们开发中期一度想把多个高级功能都塞进去结果主线联调一直没法稳定跑通。最后把所有扩展功能全部砍掉才在截止前把“水质数据-生长预测-对话建议”这条主线打磨完整。比赛评审看的是主线完成度不是功能列表长度。第三个教训是演示环节必须做离线预案。任何依赖外部网络、外部API的环节在答辩当天都可能出问题。我们最后把模型全部本地化数据库落在测试机上完整离线走演示流程走了不下十遍心里才算有底。5.3 给下一届参赛者的工具箱和三个准备清单技术栈上我强烈建议守住“成熟组件简单集成”的原则不要临场造轮子。我们用的都是社区成熟方案Python做核心逻辑FastAPI做后端Vue做前端LightGBM做表格数据建模向量库做知识检索目标检测直接用开源框架的预训练权重。这些组合的好处是文档多、案例多遇到问题搜一下就有答案。如果让我给下一届参赛者列一个准备清单我会写这三条第一选题前必须找到真实场景中愿意配合的人和真实数据源没有数据源就尽早换题。我们见过太多队伍做到一半发现网上数据无法支撑项目临时转向最后成品很单薄。第二答辩前至少安排三场模拟答辩每场找两个“会挑刺”的同学来问问题。我们在正式答辩前被队友轮番提问把很多盲点提前暴露出来了。特别是技术边界类问题“如果XXX怎么办”提前演练过现场答起来区别非常大。第三文档要把“为什么这么做”写清楚。评委看文档的速度比我们想象中快他们首先找的是选题动机和逻辑链条而不是算法公式。我们文档里专门写了两页“为什么不是传统软件而是智能体”的分析后来评委提问时明显围绕那边的讨论最多。5.4 最后说点真心话比赛结束之后我们几个人把项目代码封了档但“养一只自己的龙虾吧”这个项目带来的影响还在持续。前阵子基地负责人还在用我们部署的测试系统记录水质说他以前完全不看数据现在每天早上去看一遍趋势图已经成习惯了。我自己最大的感受是参加AI智能体创新大赛比拿奖更有用的是完整经历了一遍“从模糊想法到可用样例”的全过程。做一个通用智能体Demo容易做一个能落到具体场景里、经得起真实数据检验的智能体需要的不只是模型能力更是对问题的理解深度和工程落地的耐心。“养一只自己的龙虾”这个项目教会我最大的一件事是AI技术的价值不在于最多人用的框架而在于最合适的时间出现在最需要它的场景里。就算那只是一个养殖池边的小小屏幕也足够让一个项目感到骄傲了。