Axiara：参考价格，为什么不能自动变成正式价格？

一个好用的报价助手，不能只交出一个数字。它还需要保留一个重要区别：这是找到的信息，还是已经有人确认可以采用的信息？

Axiara 在成本查询与报价场景里探索这个区别。出发点不是「Agent 能做多少事」，而是「每种来源和工具，应该被允许影响哪些决定」。

三种信息，不是同一种地位

正式价格底稿、旧文档里的价格、最近一次市场观察，都可能有用，但它们不能互相冒充。

• main：正式底稿，由人工维护。
• learn：从历史文档中整理学习的参考信息。
• market：按需要收集的市场参考信息。

learn 与 market 可以参与判断，却不能直接覆写正式底稿。先有这个产品选择，才有三层数据的技术组织方式。

一个具体例子：值得再看一眼的价格

设想某份待审核报价里，一个条目的价格既不同于正式底稿，也不同于近期的市场参考。

审核应该把这些差异提出来，而不是悄悄认定「最新的一定正确」，顺手改掉正式价格。下一步可能是核对来源、理解上下文，也可能是请负责底稿的人确认。

这是一个用来说明边界的假设场景：收集到证据，与获准改变正式数据，是两回事。

四种模式，划分权限，不规定固定旅程

仓库里的归档、查询、批量报价和审核，定义的是能力边界，不是必须依次经过的四个界面。

• 归档：维护正式价格或整理参考资料，同时遵守相应的写入限制。
• 查询：查单个项目的正式成本、市场区间与工艺说明。
• 批量报价：按模板与约束处理 Excel 或 BOM 条目。
• 审核：对照底稿和参考信息，找出报价里值得复核的异常。

问一个条目的价格，不必启动一整套批量流程；允许审核一份报价，也不等于允许修改正式价格库。

边界不能只写在提示词里

Axiara 用 FastAPI 提供服务、LangGraph 组织 Agent，并划分数据层和工具权限。提示词可以解释规则，存储和工具的边界则给规则一个能落实的位置。

我希望 Agent 减少的是围绕决定反复收集和核对的工作，而不是把「谁有权做这个决定」藏起来。

可以继续读 Axiara 的产品故事，或查看仓库中的架构与模式定义。技术细节核对于 2026 年 9 月 6 日。