주기는 바뀌지 않았습니다. 단지 도구가 더 많아졌을 뿐입니다.

도구를 추가하려면 몇 곳을 이동해야 합니까?

S01의 상담원은 bash만 알고 있습니다. read_file / write_file / edit_file에서도 작동하도록 하려면 어떻게 변경하시겠습니까?

많은 사람들의 첫 번째 반응은 '변경 루프'입니다. 잘못된. 루프의 한 줄도 건드리지 마세요. 다음 세 가지만 필요합니다:

루프가 tool_use 블록을 발견하면 block.name을 눌러 디스패치 맵에서 함수를 검색하고 실행한 다음 출력을 tool_result에 다시 넣습니다. bash와 정확히 동일한 경로를 따릅니다.

# Dispatch map: name → handler lambda
TOOL_HANDLERS = {
    "bash":       lambda **kw: run_bash(kw["command"]),
    "read_file":  lambda **kw: run_read(kw["path"], kw.get("limit")),
    "write_file": lambda **kw: run_write(kw["path"], kw["content"]),
    "edit_file":  lambda **kw: run_edit(kw["path"], kw["old_text"], kw["new_text"]),
}

파견이 어떻게 전달되는지 확인하세요

아래 위젯을 사용하면 모델에서 보낼 수 있는 tool_use 요청을 클릭하여 해당 요청이 특정 Python 함수로 라우팅되는 방식을 확인할 수 있습니다. 참고: block.name은 어떤 줄을 사용할지 결정합니다.

safe_path : 생략할 수 없는 방어선

에이전트에게 파일 접근 권한을 부여해주세요. 가장 가능성이 높은 안전 문제는 경로 탈출입니다. 모델은 /home/user/project/에서 작동해야 했지만 결국 read_file("../../etc/passwd")을 전송하게 되었습니다.

s02에는 이를 처리하는 작은 함수가 있습니다:

def safe_path(p: str) -> Path:
    path = (WORKDIR / p).resolve()  # 规范化，解析 .. 和软链
    if not path.is_relative_to(WORKDIR):
        raise ValueError(f"Path escapes workspace: {p}")
    return path

핵심은 .resolve() + .is_relative_to() 두 단계에 있습니다. 절대 경로를 구문 분석한 다음 아직 샌드박스에 있는지 확인하세요. 전자가 없으면 foo/../../etc이 통과할 수 있습니다. 후자가 없으면 검사도 수행되지 않습니다.

경로 보안 식별

다음 5개 경로는 모두 모델에서 전송할 수 있는 read_file 매개변수입니다. safe_path에 의해 허용되는 것은 무엇이며 거부되는 것은 무엇입니까? WORKDIR = /home/user/project을 가정합니다.

에이전트에 위험한 도구를 추가하지 마십시오

도구를 추가하는 것은 쉽지만 추가하는 모든 도구는 모델의 새로운 기능 경계입니다를 기억하세요. s02에서는 bash에 이미 블랙리스트(rm -rf /, sudo, shutdown)가 있고 write_file에는 safe_path 제한이 있습니다. 제작에 도구를 추가하기 전에 스스로에게 세 가지 질문을 던져보세요.

• 이 도구를 사용하면 모델이 되돌릴 수 없는 작업을 수행할 수 있나요? (rm, 이메일 보내기, git push)
• 무엇이유출될 수 있나요? (환경 변수, .ssh, 쿠키)
• 오류 출력이 명령 피드백으로 처리됩니까? (도구 출력을 통한 신속한 주입)

강의 s07에서는 이러한 결정을 코드에서 꺼내 선언적으로 만들기 위해 "권한 계층"을 추가할 것입니다.

(点上面任意一条 tool_use 触发路由)

def run_glob(pattern: str) -> str:
    import glob
    return "\n".join(glob.glob(pattern))