Axiara

成本查询与报价，会同时碰到几种信息：正式价格底稿、历史文档里的经验，以及不断变化的市场价格。如果把它们当成同一种数据，一个整齐的答案也可能很难判断是否可信。

我希望 Axiara 帮忙完成报价周围的工作：收集信息、找到参考、批量填写、检查异常，同时保留每种来源的地位。

核心选择是把正式底稿、历史学习资料和市场信息拆成三层。历史文档和抓取价格都可以参与判断，但不能因为被 Agent 找到了，就自动变成正式价格。

正式的 main 层由人工维护，learn 与 market 层分别有自己的写入边界。我把它看作产品模型的一部分：谁可以改动一个价格，比让每一步都自动完成更重要。

归档、查询、批量报价和审核，对应的是能力与权限边界，不是一套固定的界面顺序。一个任务不需要依次走完四种模式。

• 归档：在各自权限内维护带版本的正式价格，整理历史资料与市场参考。
• 查询：查单个项目的正式成本、市场区间与工艺说明。
• 批量报价：按模板与约束处理 Excel 或 BOM 条目。
• 审核：对照正式底稿与市场参考，标出报价中值得复核的异常。

FastAPI 对外提供服务，LangGraph 承载 Agent 编排；数据使用 SQLite，并保留 CSV、YAML 等文件优先的组织方式。分层的意义，是让信息来源与允许的用途足够明确，而不是只在提示词里叮嘱一句「不要乱改」。

例如，某次市场观察与正式底稿不同，它可以成为审核时的参考，却不应该悄悄覆写底稿。收集证据和批准变更，是两种不同的动作。

服务、数据分层与业务模式，搭起了 Axiara 的基础。接下来值得继续打磨的，是一个个具体任务：查询一个条目、准备一批报价，以及解释为什么某个价格值得复核。

我想持续检验的是：一个人能不能顺着结果找到输入依据，并清楚知道哪一步仍需要自己判断。Agent 能把这些事情说明白，才值得留在工作流程里。