Agent100参赛指南：从零搭建可复现的智能体实践项目

1. 从一纸征集通知说起：Agent100 到底在找什么样的智能体

看到“Agent100”这个征集活动的通知，我第一反应不是去翻报名细则，而是先琢磨一件事：为什么是“100”，而不是“十佳”“TOP50”或者“年度最佳”？这个数字背后其实藏着一套很实在的筛选逻辑。100 个案例，意味着主办方要的不是几个孤零零的炫技 Demo，而是一批能覆盖不同行业、不同技术路线、不同落地阶段的实践样本。换句话说，他们想看的不是“我做了个智能体”，而是“我的智能体在什么场景下、用什么技术组合、解决了谁的什么问题、跑出了什么可复现的结果”。

这个征集活动把“智能体、大模型、具身智能”三个词并列放在标题里，本身就释放了一个很明确的信号：单纯的对话机器人已经不够看了。2026 年的智能体实践，至少要在三个维度上拿出东西来——大模型作为认知底座的能力调用、智能体作为任务执行体的编排逻辑、具身智能作为物理世界接口的感知与行动闭环。你可以只做其中一块，但评审视角大概率会从这三个维度去交叉审视你的项目。

我仔细看了通知里提到的征集方向，结合这两年我在智能体项目上踩过的坑，发现一个很关键的转变：早期大家做智能体，喜欢比谁接的模型多、谁的工具库全、谁的 Prompt 写得花哨。但现在评审和行业关注的重点已经转移到“任务完成率”“异常恢复能力”“多轮交互中的状态保持”这些更硬核的指标上。这其实对参赛者提出了更高的要求——你得能说清楚你的智能体在什么条件下会失败，以及你设计了什么机制让它失败之后还能兜回来。

适合参考这篇内容的人，我大致分了三类。第一类是有想法但还没动手的开发者，手里有一个场景痛点，想用智能体去解，但不确定技术选型和实现路径；第二类是在做智能体项目但卡在某个环节的团队，比如工具调用不稳定、多智能体协作乱套、具身智能仿真到真机迁移困难；第三类是想通过参赛来梳理自己技术栈的从业者，需要一个结构化的框架来审视自己的项目到底处在什么水平。这三类人看这篇内容的角度不一样，但都能从后面的拆解里找到对自己有用的东西。

2. 拆解 Agent100 的评审逻辑：他们到底在看什么

2.1 从“能跑通”到“能复用”的评分转向

我参与过几次类似的技术征集评审，也帮朋友看过参赛材料，发现一个很普遍的问题：很多人把智能体项目写成了“功能清单”。比如“我的智能体支持 20 种工具调用、接入了 5 个大模型、能处理 8 类任务”。这种写法在 2024 年可能还能唬人，但到了 2026 年，评审看一眼就会问：这 20 种工具里，有多少是你自己封装的？5 个大模型是简单路由还是做了融合推理？8 类任务的完成率分别是多少？

Agent100 这个活动的征集通知里虽然没有明说评分细则，但从它强调“实践成果”而不是“技术方案”这个措辞来看，评审重心一定在“可复现的落地效果”上。我推测他们的评分维度大概会落在这么几个方面：场景的真实性和痛点强度、技术方案的合理性和创新性、结果的量化程度和可验证性、以及方案的可迁移性和复用价值。这四个维度里，最容易拉开差距的其实是最后一个——可迁移性。很多项目在特定数据集或特定硬件上跑得很好，但换一个环境就崩，这种项目在评审眼里就是“实验室玩具”，拿不到高分。

2.2 大模型选型：不是越大越好，而是越合适越好

通知里把“大模型”单独列出来，说明评审会关注你在模型选型上的思考。我见过太多项目一上来就说“我们用了某某千亿参数模型”，但问为什么选这个模型，回答往往是“因为它效果最好”。这个回答在评审场景下是减分的。效果最好是一个结果，不是一个理由。你需要说清楚的是：在你的场景下，延迟、成本、隐私、可控性这几个约束条件分别是什么，然后你在这个约束空间里找到了哪个最优解。

举个例子，如果你做的是销售智能体，需要实时响应客户的追问，那延迟就是硬约束，这时候一个 7B 到 13B 的模型经过领域微调，可能比一个千亿模型直接零样本推理更合适。如果你做的是科研论文辅助写作，那生成质量和事实准确性权重更高，这时候用大模型加检索增强生成就是更合理的路径。评审想看到的是这种“约束条件下的权衡”，而不是“我用了最大的那个”。

还有一个容易被忽略的点：模型的可替换性。你的智能体架构是不是和某个特定模型强绑定了？如果明天要换一个模型，你的 Prompt 模板、工具调用格式、输出解析逻辑需要改多少？我在实际项目里会刻意把模型调用层抽象出来，用统一的接口去适配不同模型，这样在参赛时也可以展示“同一套智能体逻辑在不同模型上的表现对比”，这本身就是很有说服力的实践成果。

2.3 智能体框架：平台搭建和代码搭建的边界在哪里

热词里有一个问题被反复提到：“利用平台构建的智能体与用 Python 构建的智能体有什么不一样？”这个问题在 Agent100 的参赛场景下特别关键，因为评审会看你对自己技术选型的理解深度。平台搭建的优势是快，可视化编排、内置工具库、一键部署，适合验证想法和快速出原型。但平台搭建的智能体在复杂状态管理、自定义工具集成、性能调优方面往往有天花板。用 Python 从零搭建或者基于开源框架搭建，灵活度高，但开发周期长，很多基础设施要自己造。

我的建议是：如果你的参赛项目核心创新点在“场景洞察”和“交互设计”上，用平台搭建完全没问题，但你要在材料里说清楚平台的局限性以及你是怎么绕过去的。如果你的核心创新点在“算法优化”或“系统架构”上，那最好用代码搭建，因为评审会期待看到你对底层机制的掌控。最忌讳的是用平台搭了一个很简单的流程，然后包装成“智能体系统”，这种在初审阶段就会被筛掉。

2.4 具身智能：仿真到真机的鸿沟怎么填

具身智能是这次征集里门槛最高的方向。热词里出现了“具身智能机械臂”“xbotics 具身智能开源社区”“具身智能学习路线”，说明关注这个方向的人不少，但真正有真机落地经验的团队并不多。评审在看具身智能项目时，最关心的其实是“仿真环境和真实环境之间的差距你是怎么处理的”。如果你只在仿真环境里跑通了抓取任务，那只能算阶段性成果；如果你能在真机上复现，并且给出成功率、抓取节拍、异常恢复策略这些数据，那才是完整的实践成果。

我自己的经验是，具身智能项目在参赛材料里一定要有一节专门讲“仿真到真机的迁移策略”。比如你在仿真里用了域随机化来增强策略的鲁棒性，那就要说明随机化的参数范围是怎么选的，迁移到真机后哪些参数需要重新标定，标定过程用了什么方法。这些细节才是评审想看的“实践”部分，而不是放一段机械臂抓取成功的视频就完事了。

3. 从零到一搭建参赛级智能体：我的实操路线图

3.1 场景选择：找那种“不做智能体就做不好”的问题

选场景是第一步，也是最容易走偏的一步。很多人选场景的逻辑是“这个场景热，我就做这个”，结果做出来发现用传统规则引擎也能解，智能体只是锦上添花。评审一眼就能看出这种项目的问题：你的智能体到底解决了什么非它不可的问题？

我的筛选标准是三个问题：第一，这个任务是不是需要多步推理和动态决策？第二，这个任务是不是需要调用多种外部工具或数据源？第三，这个任务是不是存在大量长尾情况，规则穷举不现实？三个问题里至少有两个回答“是”，才值得用智能体去做。比如销售智能体，它需要理解客户意图、查询产品库、计算报价、处理异议、跟进记录，这是典型的多步推理加工具调用加长尾处理，非常适合智能体。再比如考公智能体，它需要根据用户的学习进度动态调整刷题计划、解释错题、推荐资料，这也是智能体擅长的。

反例是那种“输入一段文本，输出一个分类标签”的任务，这种用微调后的小模型或者甚至传统机器学习就能做得很好，硬套智能体反而增加了延迟和不确定性。评审看到这种项目，会觉得你对智能体的边界没有清晰认知。

3.2 架构设计：把“大脑”和“手脚”分开

智能体的架构设计，我习惯用“大脑-手脚-记忆”三层来拆。大脑负责推理和决策，通常是大模型加 Prompt 工程；手脚负责执行具体操作，就是工具调用层；记忆负责状态保持和历史追溯，包括短期对话上下文和长期知识库。这三层之间的接口设计是架构的核心。

大脑层的设计要点是“约束下的自由”。你不能让大模型完全自由发挥，那样输出格式不可控；但也不能约束得太死，那样就退化成规则引擎了。我的做法是用结构化输出加少量自由文本的混合格式。比如让模型输出一个 JSON，里面包含“思考过程”“下一步动作”“动作参数”三个字段，思考过程是自由文本，动作和参数是枚举和结构化数据。这样既保留了大模型的推理能力，又保证了后续工具调用的可解析性。

手脚层的设计要点是“幂等和可重试”。工具调用失败是常态，网络超时、API 限流、参数格式错误都会导致失败。如果你的智能体没有重试机制和降级策略，那在实际运行中会非常脆弱。我会给每个工具封装一个统一的调用接口，包含超时设置、重试次数、降级返回值。比如查询天气的 API 挂了，降级返回“暂时无法获取天气信息”，而不是让整个智能体流程崩掉。

记忆层的设计要点是“分层存储”。短期记忆就是对话历史，直接放在上下文里，但要注意长度控制，超过模型上下文窗口就要做摘要压缩。长期记忆可以用向量数据库存储，把历史交互中的关键信息 embedding 后存进去，需要的时候检索出来。我在实际项目里会用“滑动窗口加摘要”的方式管理短期记忆，最近 5 轮对话保留原文，更早的对话压缩成一段摘要，这样既控制了 token 消耗，又保留了关键信息。

3.3 工具封装：让大模型“会用”比“能用”更重要

工具调用的难点不在于封装本身，而在于让大模型知道什么时候该调用哪个工具、参数怎么填。我见过很多项目封装了几十个工具，但模型经常选错工具或者填错参数，导致任务失败。这个问题的根源往往不在模型能力，而在工具描述的设计。

工具描述要包含四个要素：工具名称、功能说明、参数列表、使用示例。功能说明要用自然语言写清楚这个工具解决什么问题，什么场景下用，什么场景下不用。参数列表要说明每个参数的类型、含义、是否必填、取值范围。使用示例要给出一到两个完整的调用样例，包括输入和预期输出。这四个要素里，使用示例是最容易被忽略但效果最明显的。我实测下来，加上使用示例后，工具调用的准确率能提升 20% 到 30%。

还有一个技巧是工具分组。如果你的工具有几十个，不要一次性全部暴露给模型，而是按场景分组，根据当前对话的意图动态加载相关工具。比如销售智能体在“报价阶段”只需要价格计算和库存查询工具，在“售后阶段”只需要工单创建和物流查询工具。这样既减少了模型的认知负担，也降低了选错工具的概率。

3.4 多智能体协作：什么时候该拆，什么时候不该拆

多智能体是这两年很热的方向，但我的经验是：不要为了多智能体而多智能体。很多任务用一个智能体加多个工具就能做好，硬拆成多个智能体反而增加了通信开销和状态同步的复杂度。判断标准很简单：如果你的任务可以清晰地划分成几个子任务，每个子任务需要不同的系统提示词和工具集，而且子任务之间的依赖关系是线性的或者简单分支的，那可以考虑拆成多智能体。如果子任务之间需要频繁的双向通信和状态共享，那用一个智能体加状态机可能更合适。

我做过一个销售智能体项目，一开始拆成了“意图识别智能体”“产品推荐智能体”“报价智能体”“跟进智能体”四个。结果发现意图识别和产品推荐之间需要反复交互，拆开之后通信成本很高，而且状态同步经常出问题。后来合并成一个智能体，用状态机管理对话阶段，反而更稳定。所以多智能体不是架构先进性的标志，而是特定场景下的权衡选择。

3.5 评测体系：没有量化就没有说服力

参赛材料里最容易被评审质疑的就是“效果很好”这种模糊表述。你需要一套量化的评测体系来证明你的智能体确实解决了问题。评测体系的设计要围绕你的场景目标来定，不能随便找几个通用指标凑数。

以销售智能体为例，我会设计这么几个指标：任务完成率（成功引导客户完成下单的比例）、平均对话轮次（完成一个任务需要多少轮交互）、工具调用准确率（模型选择的工具和参数是否正确）、异常恢复率（遇到工具失败或用户负面反馈后成功恢复的比例）、人工介入率（需要转人工处理的比例）。这几个指标覆盖了效果、效率、稳定性三个维度，比单纯说“准确率 95%”有说服力得多。

评测数据的来源也很关键。最好是用真实场景的脱敏数据，如果没有，就用人工构造的测试集，但要说明构造方法和覆盖的场景分布。我一般会构造三类测试用例：正常流程用例、边界条件用例、异常注入用例。正常流程用例验证基本功能，边界条件用例验证鲁棒性，异常注入用例验证恢复能力。这三类用例的比例大概是 6:3:1。

4. 具身智能方向的特殊考量：从仿真到真机的关键跨越

4.1 仿真环境搭建：选对工具链省一半力气

具身智能项目的第一步是搭仿真环境。目前主流的仿真平台有 Isaac Sim、MuJoCo、PyBullet、Gazebo 这几个。选哪个取决于你的任务类型和硬件条件。Isaac Sim 的渲染质量和物理精度最好，但对显卡要求高，而且学习曲线陡峭。MuJoCo 的物理引擎很扎实，适合做控制策略的研究，但渲染效果一般。PyBullet 轻量易用，适合快速验证想法，但物理精度在复杂接触场景下不够。Gazebo 和 ROS 生态结合紧密，适合做移动机器人相关的项目。

我的建议是：如果你的参赛项目重点是“感知-决策-控制”的算法创新，用 MuJoCo 或 PyBullet 就够了，把精力放在算法上。如果你的重点是“视觉感知”和“人机交互”，那 Isaac Sim 的渲染能力更有优势。如果你做的是移动机器人导航，Gazebo 加 ROS 是更成熟的方案。不要在一个项目里同时用好几个仿真平台，工具链的切换成本很高。

4.2 域随机化：让策略在真机上也能活下来

仿真到真机迁移最大的障碍是“现实差距”。仿真里的摩擦力、光照、物体材质、传感器噪声都和真实世界有差异。域随机化是缩小这个差距的常用方法，核心思路是在训练时随机化这些参数，让策略学会适应不同的环境条件。

具体操作上，我会随机化这几类参数：物理参数（摩擦系数、质量、阻尼）、视觉参数（光照强度、颜色、纹理、相机位置）、传感器参数（噪声水平、延迟、分辨率）。随机化的范围不能太宽也不能太窄，太宽了策略学不到有效行为，太窄了迁移到真机还是不行。我的经验是先从仿真和真机的参数差异测量入手，比如在仿真里测一下抓取成功时的摩擦系数范围，在真机上再测一遍，两个范围的并集就是随机化的参考区间。

还有一个技巧是“课程学习”。不要一上来就做全参数随机化，而是先固定大部分参数，只随机化一两个关键参数，等策略适应了再逐步增加随机化的维度。这样训练更稳定，最终策略的鲁棒性也更好。

4.3 真机部署：标定和调试的苦活累活

真机部署阶段是最考验耐心的。仿真里跑通的策略，到真机上可能连第一步都走不通。我的经验是先把真机的标定做扎实。相机标定、手眼标定、关节零位标定，这些基础工作做不好，后面的调试都是白费。标定完成后，先用简单的轨迹测试一下控制链路是否正常，再逐步增加任务的复杂度。

调试阶段我习惯用“分步验证”的方法。把整个任务拆成几个关键步骤，比如“接近物体”“抓取”“抬起”“移动”“放置”，每一步单独验证。如果某一步成功率低，就针对这一步做参数调整或策略微调。不要一上来就跑完整流程，那样出了问题很难定位是哪个环节的错。

还有一个容易被忽略的点是“异常恢复”。真机运行中会出现各种意外：物体滑落、关节限位、传感器丢帧。你的策略需要能检测到这些异常并做出恢复动作，比如重新抓取、回到安全位置、请求人工干预。评审在看具身智能项目时，会特别关注你有没有处理这些异常情况，因为这直接关系到系统能不能在实际环境中持续运行。

5. 参赛材料撰写：怎么把技术工作翻译成评审能看懂的语言

5.1 项目摘要：用一段话说清楚“谁在什么场景下用什么方案解决了什么问题”

项目摘要是评审的第一印象，很多人写成了技术堆砌，什么“基于大模型加多智能体加具身智能”，评审看完不知道你到底做了什么。好的摘要应该像新闻导语一样，把“谁、什么场景、什么问题、什么方案、什么结果”这五个要素说清楚。

我写摘要的模板是：针对某某场景下的某某问题，我们设计了一套基于某某技术的智能体系统，通过某某核心机制实现了某某能力，在实际测试中达到了某某量化指标。这个模板看起来简单，但能把评审最关心的信息都覆盖到。比如“针对电商客服场景下多轮对话中意图漂移和工具调用错误率高的问题，我们设计了一套基于大模型加状态机的智能体系统，通过动态工具加载和结构化输出约束实现了稳定的多轮任务执行，在 500 条真实对话测试集上任务完成率达到 87%，工具调用准确率达到 92%。”

5.2 技术方案：讲清楚“为什么这么选”比“选了什么”更重要

技术方案部分是评审重点看的部分，也是最容易写成“技术清单”的部分。我的建议是采用“问题-约束-方案-验证”的叙述结构。先说清楚你面临的技术问题是什么，然后说明在这个问题上有哪些约束条件（延迟、成本、数据隐私、硬件限制），接着讲你在这个约束空间里选择了什么方案以及为什么，最后给出验证结果。

比如在讲模型选型时，不要只说“我们用了某某模型”，而是说“我们的场景要求端到端延迟低于 2 秒，同时需要处理大量领域专有术语，通用大模型在术语理解上准确率只有 70% 左右。我们对比了直接调用通用大模型、通用大模型加检索增强、以及领域微调小模型三种方案，在延迟和准确率的权衡下选择了领域微调小模型加检索增强的混合方案，最终术语理解准确率提升到 89%，端到端延迟控制在 1.5 秒以内。”

5.3 结果呈现：用表格和对比说话

结果部分最忌讳的是只给一个孤零零的数字。评审需要看到对比，看到基线，看到提升幅度。我一般会用表格来呈现结果，表格里包含“方案”“指标 1”“指标 2”“指标 3”这几列，行是不同方案或不同配置的对比。比如对比“零样本大模型”“少样本大模型”“微调小模型”“微调小模型加检索增强”四种方案在准确率、延迟、成本三个指标上的表现。这样评审一眼就能看出你的方案优势在哪里，代价是什么。

还有一个技巧是给出“消融实验”的结果。比如你的系统有 A、B、C 三个核心模块，你可以分别去掉 A、去掉 B、去掉 C 跑一遍评测，看看哪个模块对最终效果的贡献最大。这不仅能证明你的设计是有效的，还能展示你对系统行为的理解深度。评审看到消融实验，会觉得你是认真做过分析的，而不是碰巧调出了一个好结果。

5.4 可复现性说明：让评审相信你的结果不是碰运气

可复现性是参赛材料里经常被忽略但评审很看重的一点。你需要说清楚你的实验环境、数据来源、参数配置、运行步骤，让评审相信换一个人按照你的说明也能跑出类似的结果。具体来说，我会在材料里附上这么几项：硬件配置（GPU 型号、内存大小）、软件版本（操作系统、Python 版本、关键库版本）、模型版本（模型名称、参数量、微调数据量）、关键参数（温度、top_p、最大 token 数）、运行命令或脚本入口。

如果涉及敏感数据不能公开，就说明数据的构造方法和统计特征，比如“测试集包含 500 条对话，平均轮次 6.3，意图分布为 A 类 40%、B 类 35%、C 类 25%”。这样评审虽然看不到原始数据，但能判断你的测试集是否有代表性。

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

6.1 智能体行为审计：你的智能体为什么做了那个决定

智能体行为审计是热词里出现的一个概念，在实际项目中非常有用。当智能体做出了一个不符合预期的动作时，你需要能追溯它是怎么想的。我的做法是在智能体的每一步决策中都记录“思考过程”，包括当前状态、可用工具、模型选择的动作、选择理由。这些日志在调试阶段是宝贵的排查依据，在参赛材料里也可以作为“可解释性”的佐证。

排查的时候，我会按这个顺序看：首先看模型输出的思考过程，判断它是不是理解了当前状态；然后看工具调用的参数，判断是不是参数填错了；最后看工具返回的结果，判断是不是工具本身出了问题。这三个环节里，模型理解错误和参数填写错误占了大多数。模型理解错误通常是因为系统提示词不够清晰或者上下文太长导致关键信息被淹没。参数填写错误通常是因为工具描述不够明确或者参数格式约束不够严格。

6.2 工具调用失败：从超时到降级的完整处理链

工具调用失败是智能体运行中最常见的异常。我整理了一个处理链，按顺序执行：第一步是重试，对于网络超时这类临时性失败，重试 2 到 3 次通常能解决；第二步是降级，如果重试后仍然失败，返回一个降级结果，比如“暂时无法获取该信息”；第三步是告知模型，把降级结果作为工具返回值传给模型，让模型决定下一步怎么做；第四步是记录，把失败的工具名称、参数、错误信息记录下来，用于后续分析。

这里有一个容易踩的坑：降级结果的格式要和正常结果的格式保持一致，否则模型可能解析不了。比如正常返回是 JSON 格式，降级返回也要是 JSON 格式，只是字段值表示“不可用”。我见过有的项目降级时直接返回一个字符串“error”，结果模型不知道这是什么意思，整个流程就卡住了。

6.3 多轮对话中的意图漂移：怎么让智能体记住用户到底要什么

多轮对话中，用户可能会在几轮之后改变意图，或者在一个意图中夹杂了另一个意图。智能体如果没有好的状态管理，就会“忘记”用户最初的需求。我的解决方案是在每一轮对话开始时，让模型先做一个“意图确认”的动作：根据对话历史，总结当前用户的核心意图是什么，然后基于这个意图选择工具和生成回复。

这个意图确认的动作可以是一个单独的模型调用，也可以放在主 Prompt 里让模型自己判断。我倾向于单独调用，因为这样意图总结的结果可以作为后续步骤的明确输入，减少模型在长上下文中的注意力分散。意图总结的输出格式我一般用“当前意图：xxx；已完成步骤：xxx；待完成步骤：xxx”这样的结构化文本，清晰且易于后续处理。

6.4 常见问题速查表

6.5 几个我踩过的坑

第一个坑是“过度依赖大模型的零样本能力”。早期我做智能体时，觉得大模型什么都能干，工具描述写得很简单，结果模型经常选错工具。后来老老实实给每个工具写详细描述和示例，准确率才上来。大模型的能力边界比想象中窄，尤其是在工具调用这种需要精确匹配的场景下。

第二个坑是“忽略冷启动问题”。智能体上线初期，用户不知道它能做什么，经常问一些超出范围的问题。如果没有好的引导和兜底策略，用户体验会很差。我的做法是在对话开始时给一个简短的能力说明，并且在模型判断意图不明确时主动询问澄清，而不是强行回答。

第三个坑是“评测集和训练集重叠”。有一次我构造评测集时不小心用了和训练集相似的对话，结果评测指标很好看，但上线后效果差很多。后来我强制要求评测集和训练集在场景分布和表达方式上要有明显差异，评测结果才真实可信。

7. 关于 Agent100 参赛的一些个人建议

如果你打算参加 Agent100 或者类似的智能体实践征集，我有几个很具体的建议。第一，尽早开始记录你的开发过程。很多有价值的东西是在调试中发现的，比如某个参数为什么设成这个值、某个异常是怎么解决的。这些细节在写材料时是最有说服力的，但如果不记录，过两周就忘了。我习惯用 Markdown 文件按日期记录每天的开发日志，包括遇到的问题、尝试的方案、最终的结果。

第二，找一个真实的用户来试用你的智能体。自己测试和真实用户使用是两回事。真实用户会问出你意想不到的问题，会在你没想到的地方卡住。这些反馈是改进系统的宝贵输入，也是参赛材料里“实践验证”部分的最好素材。哪怕只找到一个用户，让他用一周，收集到的反馈也比你自己闭门造车一个月有价值。

第三，不要追求大而全。Agent100 要的是 100 个实践成果，不是 100 个全能冠军。你的项目在一个细分场景里做到极致，比在十个场景里都做到及格更有竞争力。评审看的是深度，不是广度。把一个场景的痛点挖透，把技术方案做扎实，把数据测清楚，这比堆砌功能要难得多，但也有价值得多。

第四，注意材料的可读性。评审可能要在短时间内看大量材料，如果你的材料结构混乱、重点不突出，很容易被跳过。我的做法是先写一个一页纸的摘要，把核心信息浓缩进去，然后再展开写详细内容。摘要里要有场景、方案、结果三个要素，让评审在 30 秒内就能判断你的项目值不值得细看。

最后说一个我自己的体会：智能体这个方向，技术迭代很快，今天好用的方案明天可能就过时了。但有一些东西是不变的，比如对场景的深刻理解、对用户需求的准确把握、对系统行为的严谨分析。这些能力不会因为模型更新而贬值，反而是你在快速变化的技术环境中保持竞争力的根基。Agent100 这样的活动，本质上是在寻找那些真正把智能体用起来、用出效果的人，而不是那些只会追新概念的人。