1. 编码 agent 的输入失控，由于历史代码命名的问题，导致 grep 等方式，读取了大量语义相近但是未必有用的代码。在链式执行的一开始就在积累错误。 2. HATEOAS 风格接口下的 Agent 工作流，最典型的执行拓扑不是固定的链式执行，而是状态驱动的路由。 以一个“报销申请 Agent”为例。它不是预先写死“先创建申请、再上传发票、再提交审批、再查询结果”这一整条流程，而是在每一步读取服务端返回的当前状态，以及当前状态下允许执行的动作。比如报销单处于草稿状态时，系统只暴露“编辑、上传发票、取消”等动作；等发票上传完成后，系统再暴露“提交审批”；提交之后，又暴露“查询审批状态”或“补充材料”等动作。Agent 的任务不是背完整流程图，而是根据当前状态和可用动作，判断下一步该走哪条路径。 属于 Route + Loop（因为 payload 参数需要校验）。它每执行一步，都会进入一个新状态，然后重新观察当前可用动作，再次选择下一步。也就是说，它不是“一步步传下去”，而是“看当前状态，再选下一步”。 这种拓扑最容易让错误沿着错误分派的路径传播。因为关键风险在于 Agent 选错了路。如果它误读了当前状态，或者误解了某个动作的业务含义，就可能把本该继续补充材料的申请提交出去，或者把“取消编辑”误认为“取消整个申请”。一旦选错动作，外部系统状态就会被改变，后续所有可选路径也会基于这个错误状态继续展开。