【S1W3交叉评测】拾城 CityPick — 项目评测反馈 #2
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
交叉评测意见
1. 项目理解
我理解该项目为「拾城 CityPick」，是一个基于多 Agent 协同架构的城市文旅信息智能体平台。项目以临港新片区为首发验证场景，通过 7 个 AI Agent（搜索、提炼、融合、推荐、行程规划、呈现、监控）组成的流水线，解决用户「不知道去哪玩」的信息不对称问题。用户通过自然语言提问，系统自动调度 Agent 完成从信息检索到行程规划的全流程，最终以可视化卡片和时间线形式呈现结果。
项目技术栈为 Python 服务器后端（加密引擎分发）+ 纯 HTML/JS 前端，后端核心逻辑加密存储在 backend_engine.dat 中，运行时通过 backend_loader.py 解密加载。项目包含 8 项自动化测试，覆盖数据完整性、Agent 流水线、Skill 完备性、引擎加载等维度。
2. 项目优点
2.1 多 Agent 协同架构设计清晰
7 个 Agent 分工明确（Search → Extract → Fuse → Recommend → Itinerary → Present → Update），每个 Agent 职责单一、接口统一，形成了完整的可扩展流水线架构。这种设计便于后续增加新的 Agent 或替换单个 Agent 的实现。
2.2 测试覆盖完善且可执行
项目提供了 8 项自动化测试，覆盖了数据完整性、搜索功能、Agent 流水线（7 个 Agent 全链路）、Skill 完备性（9 个 Skill）、后端引擎加载、配置文件验证、构建产物检查和量化指标评估。这在同赛段项目中是较为少见的工程化实践。
2.3 项目文档详尽
README 中英文双语、SPECS 文档包含完整的痛点分析（5 大痛点、量化数据、损失估算）、解决方案描述、技术架构、评测标准等，文档体系非常完善，体现了良好的项目规划能力。
2.4 平滑数据切换设计
项目设计了 Mock ↔ Real API 的平滑切换机制，当前使用 18 条临港真实数据的 Mock 层，后续接入真实数据源时无需修改 Agent 层代码，体现了良好的架构前瞻性。
2.5 版权保护和隐私安全意识
内置了有效期保护机制（1 个月到期后引擎拒绝工作）、后端源码加密分发、用户查询仅内存处理不持久化、API Key 本地 vault 存储（权限 600）等安全措施。
3. 当前不足
3.1 后端核心逻辑闭源且加密，可验证性受限
虽然项目 README 中声明后端加密是为保护知识产权，但对于评测场景而言，评审人员无法直接审查核心引擎的实现质量、匹配算法合理性、数据融合逻辑的正确性等。仅能通过前端表现和预设的测试用例来间接评估，增加了评测的不确定性。
3.2 数据层仍为 Mock，未接入真实数据源
当前使用的 18 条临港景点/活动数据均为 Mock 数据，虽然 README 中描述了平滑切换设计，但在实际评测时无法验证项目在真实数据环境下的表现，例如数据冲突消解、时效性检查、搜索结果质量等核心能力。
3.3 缺乏前端 UI 的可用性细节
前端为纯 HTML/JS 单页，样式较为基础。缺少：移动端自适应布局、加载状态反馈（长时间查询时的进度提示）、错误处理界面（后端不可用时的降级提示）等现代 Web 应用应有的用户体验细节。
3.4 缺少对 LLM 的实际依赖
当前版本的 7 个 Agent 和 9 个 Skill 似乎完全基于规则引擎实现，未实际集成 LLM（如 DeepSeek API）。虽然规则引擎在演示场景下可行，但缺少 LLM 能力意味着：自然语言理解能力有限、不能处理模糊查询、无法生成自然语言解释。这与「AI 智能体平台」的定位有一定差距。
3.5 城市可复制的验证尚不充分
项目宣称「切换配置即可适配新城市」，但当前代码中城市间的差异（政策数据格式、景点分类体系、语言差异等）并未通过实际配置切换来验证。更换城市时是否需要修改 Agent 代码尚不可知。
4. 建议
4.1 考虑以「开源核心 + 闭源增强」模式发布
建议将核心引擎的匹配逻辑、数据融合算法以「参考实现」的形式开源一个简化版本，让评测人员和社区能够理解核心设计思路，同时保留高性能/商业化的闭源增强版本。这样可以兼顾知识产权保护和项目可验证性。
4.2 在 Mock 层增加数据质量模拟
建议在 Mock 数据中增加数据冲突场景（同一活动不同来源的价格不一致）、过期数据（超过 7 天的历史活动）、模糊查询场景等，以验证 FuseAgent 的冲突消解能力和 UpdateAgent 的时效性检查能力。
4.3 增强前端用户体验
建议补充移动端响应式布局、添加查询加载动画/进度条、增加错误状态提示页面。同时可考虑提供查询结果分享功能，方便用户保存或分享行程规划。
4.4 规划 LLM 集成路径
建议明确 LLM 在拾城架构中的集成位置（例如 SearchAgent 用 LLM 做查询理解、RecommendAgent 用 LLM 做个性化推荐解释、ItineraryAgent 用 LLM 做自然语言行程描述），并在下一个迭代中至少集成一个 Agent 的 LLM 能力。
4.5 补充跨城市配置样例
建议在仓库中附带第二座城市的配置示例（例如北京市），通过实际配置文件展示城市切换流程，验证架构的城市可复制性。至少应包括：城市数据文件格式、配置参数差异、本地化适配项。
5. 综合评价
该项目架构设计清晰、文档体系完善、测试覆盖良好，在技术设计层面展现出了较高的工程化水平。多 Agent 协同流水线的设计具有较强的可扩展性，Mock ↔ Real 平滑切换的设计也体现了架构前瞻性。核心不足在于后端闭源加密导致的可验证性受限、数据层未接入真实数据源，以及缺少 LLM 实际集成。从当前版本来看，该项目已经较清楚地说明了方向和架构设计，建议在后续迭代中补齐 LLM 集成和真实数据源接入。
自评反馈已收到。基于评测建议，v1.1 已完成以下改进：
v1.1 总分 88 分。