供应商尽职调查

准入尽调有个很别扭的特点：判断标准其实就那么几条——工商状态是否正常、有没有重大涉诉、历史履约逾期率是否超阈值、资质是否在有效期内。这些标准写在采购制度里，明明白白。但每新增一家供应商，就要有人把这几条重新执行一遍。

而且执行得并不整齐。赶进度的时候涉诉只查了近一年，宽松的时候查了近三年；甲查了失信名单，乙忘了查。查到的材料散在各人电脑和聊天记录里，半年后审计问起来，拿不出完整的核查过程。

这是实施时最容易做错的一步。很多人会把"逾期率超过 10% 即预警"直接写进智能体的角色设定，然后复制出五六个变体分给不同品类。等采购制度修订、阈值从 10% 调到 8%，你要去找那五六份提示词——通常会漏掉一两份。

正确的做法是把准入标准连同判定口径打包成 Skill：逾期率上限、涉案金额红线、资质有效期要求、各品类的差异化规则都放在技能文件包里。技能支持版本管理，标准修订时发新版本，所有加载它的智能体自动对齐。制度和实现之间只有一条更新路径。

外部数据源接成连接器：工商、涉诉、失信这类查询接口用插件封装成单次 REST API 调用；如果数据方已提供 MCP 服务，直接接 MCP 工具。二者在 Cowork 市场里统一归到「连接器」分区，接一次全员复用。

工作流的开始节点接收进围名单，代码执行节点先解析出主体名称与统一社会信用代码——这一步不能交给模型，名单里的错别字、简称、括号备注需要用规则清洗，而不是让模型"理解"。清洗后进循环节点，逐家并行跑三条核查线。

判定环节坚持用代码算。逾期率、涉案金额合计、是否超阈值全部在代码执行节点里计算。模型只负责把已经算好的结果组织成可读的结论和风险对照表。这不是不信任模型，是因为尽调结论要拿去支撑准入决策，数字必须每次算都一样、并且能被复核人手工验算。

任务执行日志完整记录了每一步调用了哪个连接器、传了什么参数、拿回什么结果；平台侧的关键操作由审计日志记录操作人、时间、对象与来源 IP。

这意味着半年后审计来问"这家当初为什么判定通过"，能从结论逐条退回到原始查询返回，而不是靠经办人回忆。对尽调这类留痕要求高的场景，这一点往往比效率提升更重要。